WEBVTT 00:00.000 --> 00:10.000 Keeping your application secure by evolving allows two-point-over and open-minded connect. 00:10.000 --> 00:15.000 Welcome to this talk here. First time having to be here, I'm one of the kick-lock maintainers. 00:15.000 --> 00:19.000 There are about ten kick-lock maintainers at the moment. 00:19.000 --> 00:25.000 Yeah, let's give it a start. So it's all about this epic quest of single sign-on. 00:25.000 --> 00:28.000 I'm a little bit more than single sign-off, of course. 00:28.000 --> 00:33.000 You want to share your identity and delegate resource access to select services. 00:33.000 --> 00:35.000 So that's the high level goal we want to do. 00:35.000 --> 00:37.000 We want to do that, of course. 00:37.000 --> 00:40.000 Security. We want to keep our credentials secure, so we don't. 00:40.000 --> 00:45.000 We share them eventually our credentials within identity provider, but not with the applications. 00:45.000 --> 00:50.000 And we want to let applications operate on our data when they're permitted. 00:50.000 --> 00:54.000 So all the internet is about APIs and we want to then have applications, 00:54.000 --> 00:59.000 interact on APIs on all behalf when and if we want that. 00:59.000 --> 01:03.000 So that's very high level of direction, and where do we come from? 01:03.000 --> 01:09.000 So we come from, well, a sum of two-point-over, that's XML, that's 2005. 01:09.000 --> 01:13.000 And it worked very well for single sign-on, so you can authenticate to an application, 01:13.000 --> 01:16.000 and they know it's you and we have assertions on all that. 01:16.000 --> 01:24.000 But then we looked for great alternatives that were not XML to do like posting funny pictures 01:24.000 --> 01:26.000 on social media. 01:26.000 --> 01:34.000 So they came up with OS 2.0, our OS 1.0 was then considered two complex two post pictures on social media. 01:34.000 --> 01:42.000 And then OS 2.0 was just the right complexity, just the right security to post those funny memes and reply on things. 01:43.000 --> 01:49.000 And open-mindy connect came eventually because we also want to do like a little bit of identity to it, 01:49.000 --> 01:51.000 and that's like more than 10 years ago. 01:51.000 --> 01:52.000 That's the past. 01:52.000 --> 02:01.000 We made some decisions, and then we found out, well, something that's good to post a picture on Twitter is not good enough to do actually banking with it. 02:01.000 --> 02:10.000 So people set down, and then in 2021 they came up with FarPie 1.0, that's like the basis of open banking. 02:10.000 --> 02:14.000 So in a lot of countries you can know you've open banking, your banks still have your account, 02:14.000 --> 02:21.000 and do the proper money stuff with it, but thinnups can connect your accounts, and to have better account management, 02:21.000 --> 02:23.000 analyze your transactions, all these things. 02:23.000 --> 02:31.000 And by the way, all these lights are already uploaded, so they are linked from the first time talk page in the PDF, 02:31.000 --> 02:35.000 and you can also click the links in whatever you're on there. 02:35.000 --> 02:40.000 So that was 2021, and it was so popular that they now evolved it. 02:40.000 --> 02:46.000 And in the last year they had the best current practice of all of 2.0 as an RFC published. 02:46.000 --> 02:51.000 So I think that's a very, very humble title, best current practice. 02:51.000 --> 03:00.000 And also FarPie 2.0 was published last year, and so FarPie 1.0 was posted on the great marketing success I have to say, 03:00.000 --> 03:06.000 when it comes to the name FarPie, and then they still call it FarPie 2.0, the F4 financial originally, 03:06.000 --> 03:15.000 but then the F also for the F in e-health and the F in public e-government services. 03:15.000 --> 03:21.000 And of course, it's going to be better, even better this year, like the very latest old house 2.1, 03:21.000 --> 03:28.000 about to be published this year, that's already a draft, and but it will not be so much different from FarPie 2.0. 03:28.000 --> 03:35.000 I would say, and the current best practice. So what I'm doing today is mostly focusing on FarPie 2.0, 03:35.000 --> 03:40.000 but the concepts will apply to over 2.1 as well. 03:40.000 --> 03:49.000 And what the FarPie people really did well, at least well, especially in the 2.0 world here, they wrote down their security assumption. 03:49.000 --> 03:58.000 Like, what are we assuming, then, is secure, what does not secure, and how do attackers work in that space of almighty connectivity, 03:58.000 --> 04:01.000 all the infrastructure that powers our application today? 04:01.000 --> 04:09.000 And they came up with some attacker personas, and then what is assumed to be secure, and what can be compromised? 04:09.000 --> 04:16.000 And they assume, well, TLS is safe, except when there's maybe a house leader something, 04:17.000 --> 04:23.000 but they assume it's secure, and we will have more details when you are safe to assume it's here as a secure. 04:23.000 --> 04:28.000 All this sharing of public keys is also assumed to be secure. 04:28.000 --> 04:36.000 I mean, do it in the right way, just trade WPS for almighty connect, and browse in the end points are assumed to be reasonably secure. 04:36.000 --> 04:42.000 And finally, identities and certain management, at least in the scope of FarPie 2.0 are also considered secure. 04:42.000 --> 04:47.000 So, what that means, for example, FarPie doesn't care about stolen passwords. 04:47.000 --> 04:52.000 It doesn't care about stolen cookies, so much when it comes to maybe a session cookie for an IDP. 04:52.000 --> 04:59.000 That's a different topic, it's more considered out of scope, and hopefully handled it well by your respective IDP, 04:59.000 --> 05:04.000 and that the identities may be used wrong authentication, that's also not part of FarPie. 05:04.000 --> 05:10.000 But that leaves a lot of things to do to do really secure almighty connect. 05:11.000 --> 05:18.000 So, the attacker models they have in FarPie 2.0, they also listed a number, let's have a show look at that. 05:18.000 --> 05:25.000 So, we have web attackers, the web attackers can call basically any year I, or they make the users tick on links, 05:25.000 --> 05:30.000 but they can't break encryption, they can't break TLS, so that's this attacker type number one. 05:30.000 --> 05:35.000 A attacker type number two, they will spy on the network, but they can't break TLS encryption, 05:35.000 --> 05:39.000 so that's very good TLS encryption comes into play as well. 05:40.000 --> 05:45.000 Some people might be maybe browser plugins or so, might even spy on what's happening in the browser URL, 05:45.000 --> 05:50.000 so they could look at this authorization request in the browser, and so they are not. 05:50.000 --> 05:56.000 Some attackers might have access to those, so you might want to protect against this kind of attacks. 05:56.000 --> 06:05.000 And one of those, whatever was thinking like what the heck, but well, there might be a attacker to read the proxy lock, 06:05.000 --> 06:10.000 so the resource owner, request blocks, but they can't read the sponsors. 06:10.000 --> 06:15.000 So, imagine that attacker is on a network, reading your incoming HTTP request, 06:15.000 --> 06:18.000 but not being able to read the outgoing HTTP request. 06:18.000 --> 06:26.000 So, it's strange, but that's actually a web application firewall, like it might receive all the traffic analysed, 06:26.000 --> 06:33.000 and you might then design your protocols to be secure enough to be intercepted by a web application firewall. 06:34.000 --> 06:43.000 And yeah, with these attackers and these other things to be assumed secure, you can then dive into securing a transport player. 06:43.000 --> 06:48.000 That's the basis of, I'd say, everything on the internet, and what Farbie then really rides down, 06:48.000 --> 06:54.000 and if you're securing your infrastructure at home, if you're securing the infrastructure at your companies, 06:54.000 --> 06:59.000 well, they ride down, you should use TLS 1.2, or better, right? 06:59.000 --> 07:02.000 That's, I think, common sense, hopefully. 07:02.000 --> 07:06.000 Also, to a certificate stack, you should do an stack. 07:06.000 --> 07:11.000 So, people don't get directed to the wrong DNS in some places. 07:11.000 --> 07:21.000 You should use only security LSI for this, meaning the bottom line might be everything that supports perfect for the privacy. 07:22.000 --> 07:32.000 So, whenever a good client or browser comes to a server for the first time, the server will tell the browser, 07:32.000 --> 07:39.000 I'm using TLS, I'm using TLS all the time, and when you come back, please ensure that they're using TLS as well, 07:39.000 --> 07:44.000 even if somebody's trying to redirect it to an HTTP only page. 07:44.000 --> 07:48.000 So, that's the basic stuff, it's common sense, but, 07:48.000 --> 07:57.000 and then the company environment is always good to have it on paper somewhere, to put this common sense to a checklist and to have people actually implemented. 07:57.000 --> 08:08.000 So, that part of Farbie 2.0, and the next thing is, then, how to really, for example, secure this allowed to authorization code flow. 08:08.000 --> 08:13.000 That's been around for more than 10 years, I've seen in a very first slide, 08:13.000 --> 08:19.000 and, like a very, very short refresher on that, where things might go wrong in this way. 08:19.000 --> 08:24.000 So, we are redirecting people to the IDP to also authorization endpoint, 08:24.000 --> 08:27.000 and then you have, like, URL parameters. 08:27.000 --> 08:31.000 The redirect to the line, the login prompt might not be so sensitive, 08:31.000 --> 08:36.000 but you might put in the scope that you're asking for to the authorization level. 08:36.000 --> 08:40.000 So, people should not be able to read that so much, so you want to protect that one. 08:40.000 --> 08:45.000 When you then get back to the code from the IDP, you want to protect it as well, 08:45.000 --> 08:52.000 because, again, in a URL, it's been redirected, and people should not read that and, and visit. 08:52.000 --> 09:02.000 When you then post the code to the code, to the IDP, the IDP really wants to make sure that this code that's being posted is really belonging to this user, 09:02.000 --> 09:05.000 and to the client, and not to anybody else. 09:05.000 --> 09:08.000 And when you refreshing token, it's almost the same. 09:08.000 --> 09:13.000 You're sending refresh token and getting back new tokens, new access token, 09:13.000 --> 09:20.000 and you want to make sure that this token that's being received is only being used by the client, 09:20.000 --> 09:22.000 and the user, nobody else. 09:22.000 --> 09:27.000 And when you call API endpoint, you send usually a viewer token, and this viewer token, 09:27.000 --> 09:32.000 can be, if you use it in this way, being exchanged with any other request, 09:32.000 --> 09:37.000 can be probably used with other APIs as well, and you don't want that. 09:37.000 --> 09:42.000 So with all these things that you don't want, so let's see what Farpy can do about that, 09:42.000 --> 09:47.000 or the standards that were incorporated into Farpy. 09:47.000 --> 09:51.000 And the best practices around that, as well, use TLS for all endpoints. 09:51.000 --> 09:58.000 If you're not using TLS for all your endpoints, you like to redirect, then you're probably in the bad place. 09:59.000 --> 10:04.000 This resource on the password grant, it's been deprecated and not recommended. 10:04.000 --> 10:13.000 It's not part of Farpy 2.0, and if you go to the OS 2.1, it's actually forbidden to use it anymore. 10:13.000 --> 10:19.000 So no resource on the password grant has been around for a time, but for the secure stuff, you don't really want to use it. 10:19.000 --> 10:26.000 You'd want to have no wildcars near redirect, you don't want to have, you always want to have a private key, 10:26.000 --> 10:30.000 you don't want to create a JWT, you don't want to have public lines. 10:30.000 --> 10:35.000 You don't want to have this, I'd say, using a password kind of secrets for your clients, 10:35.000 --> 10:37.000 it's just a string that you send. 10:37.000 --> 10:45.000 So Farpy makes really, really sure that you're doing the good stuff of all of us 2.1. 10:45.000 --> 10:50.000 Some things I would go into more details like, it's now first authorization request, 10:50.000 --> 10:54.000 fixed C and send a constraint tokens. 10:54.000 --> 11:00.000 So this is kind of the, but the other stuff is probably all your clients can hopefully do that, 11:00.000 --> 11:05.000 but these things might be a bit more advanced, and I will have a short example on those. 11:05.000 --> 11:13.000 So first authorization request for the idea of not putting everything in this redirected your eye, 11:13.000 --> 11:17.000 that you're putting in your browser and redirect to your IDP. 11:17.000 --> 11:21.000 So the idea is that you add one more extra request. 11:21.000 --> 11:27.000 I must have one, anybody got in the client, send to the IDP request with all the things that they will 11:27.000 --> 11:32.000 usually put in the redirected to the browser and then to the IDP. 11:32.000 --> 11:38.000 But as this is then see, let's encrypt it, it's using the public and private key of the clients. 11:38.000 --> 11:42.000 It's really secure, the IDP controls that it comes from a trusted source. 11:42.000 --> 11:46.000 It will not be visible in a browser, so that's just secure way to send things. 11:46.000 --> 11:53.000 And it will receive an ID, actually it's an your eye in the end, but that's more or less a play token. 11:53.000 --> 11:57.000 And then it in the second step sends, instead of all these requests parameters, 11:57.000 --> 12:03.000 takes this token and put it through the URL and nobody can really make any use of that. 12:03.000 --> 12:09.000 And once that arrives at the IDP, the IDP will know about this information has been passed on instead. 12:09.000 --> 12:16.000 And like this way, the redirected URL that the browser sees is opaque. 12:16.000 --> 12:19.000 It doesn't contain any sensitive information. 12:19.000 --> 12:29.000 It can't be manipulated and it's making it secure. 12:29.000 --> 12:36.000 Then the authorization code, the authorization code, it should not be replayed. 12:36.000 --> 12:41.000 It should not be finished, it should not be used by somebody else and how you can prevent against that. 12:41.000 --> 12:47.000 The client will send a code to challenge at the start of the authorization flow to the browser. 12:47.000 --> 12:54.000 The browser will send that to the IDP and the code flows back to the client. 12:54.000 --> 13:01.000 And in the last step, where we exchange the code with the tokens, we will send a code verifier from the client to the IDP. 13:01.000 --> 13:14.000 And this makes, and then the IDP will check that this code that has been generated will only be turned into tokens to that one client that has the proper verifier 13:14.000 --> 13:19.000 and only the client that has the proper verifier is then the right client to receive the token. 13:19.000 --> 13:21.000 So that's fixing. 13:21.000 --> 13:26.000 The other thing is then send a constraint tokens, for example with D-pop. 13:27.000 --> 13:39.000 So the idea is that whenever you present an access code as a client, you make sure that you are the client that actually was granted this access token. 13:39.000 --> 13:44.000 And you do that within the femoral key pair, that's the client venerates. 13:44.000 --> 13:50.000 So when you do a public client, both public clients and authority, but it works also with public clients. 13:50.000 --> 13:53.000 I showed that there are last years for them. 13:53.000 --> 13:58.000 This authorization code flow can use work by the wastixi or T-pop. 13:58.000 --> 14:08.000 And then in the very, all this communication is done between the client and the IDP using already this property elasticity. 14:08.000 --> 14:14.000 But once the client calls any of the APIs, it will use this. 14:14.000 --> 14:22.000 An authorization had a wast-pop and some additional information that binds that access code to another thing that. 14:22.000 --> 14:29.000 That's all that the signature that the client is posting together with the access token to the API. 14:29.000 --> 14:31.000 Let's see that as an example. 14:31.000 --> 14:40.000 So the thing is whenever an API received something, the HTTP method, the URI, the D-pop proof, the access token, and non-s. 14:40.000 --> 14:43.000 They only to the line, otherwise something is wrong. 14:43.000 --> 14:49.000 So you calling this API with an authorization D-pop, and access token plus the D-pop proof, 14:49.000 --> 14:54.000 which basically encapsulate an e-credigratic way, this method, and the URI is being called. 14:54.000 --> 15:00.000 Whenever somebody tries to use it on a different API, if somebody tries to use it on a different API, if somebody tries to use it on a different UI, 15:00.000 --> 15:05.000 or method, then it will just fail because this proof will not fit any more. 15:05.000 --> 15:06.000 Then it sends it to the server. 15:06.000 --> 15:11.000 The server might say, I accept it immediately or it sends back a non-s. 15:11.000 --> 15:20.000 It runs like a one-time use token, and then the client should try again, with a new D-pop proof here, 15:20.000 --> 15:24.000 with that non-s, and then finally the API responds with OK. 15:24.000 --> 15:32.000 A lot of overhead, but then hopefully to make it secure when work with application files, 15:32.000 --> 15:40.000 and then like a stone token can no longer be used to do anything else, but this exact API call because it's bound. 15:40.000 --> 15:46.000 So, well, I'm a kick-up maintainer, so all of that has not been able to kick-up so far, 15:46.000 --> 15:53.000 but then kick-up is more than the 10 years old, but it's been evolving to include all these standards, 15:53.000 --> 15:58.000 and there are at the moment opt-in, so we can use them, but or not use them. 15:58.000 --> 16:02.000 We have now, it's open source, 100% open source. 16:02.000 --> 16:06.000 It has, well, these 3,000 kit-up stores, which is very nice. 16:06.000 --> 16:11.000 And we support a lot of standards, but including this Fabi 2.0 security profile, 16:11.000 --> 16:16.000 and also the ORS 2.1 authorization framework draft. 16:16.000 --> 16:19.000 And how does kick-up help you with that? 16:19.000 --> 16:24.000 I'm sure you demo how you can enforce the Fabi 2.0 security profile with kick-up, 16:24.000 --> 16:27.000 so that you can level up within your organizations. 16:27.000 --> 16:32.000 So, these are the screenshots, it takes the demo goes wrong. 16:33.000 --> 16:39.000 So, what you can do, there are something called client policies. 16:39.000 --> 16:45.000 In kick-lough, so there are different profiles, a lot of Fabi and others, 16:45.000 --> 16:51.000 or two woodborne, but I can have a policy here. 16:51.000 --> 16:57.000 Fabi 1 baseline, CBA, Fabi 2 security profile, so I can select from different policies, 16:57.000 --> 17:02.000 and what I then did. I set up a policy called all secure Fabi 2.0 clients, 17:02.000 --> 17:08.000 so I want to apply this policy to all the applications that are now certified to be secure 17:08.000 --> 17:11.000 and capable enough to do Fabi 2.0 properly. 17:11.000 --> 17:16.000 I assign this client profile to it here, and I assign it, 17:16.000 --> 17:20.000 like all the clients that have a specific client role secure, 17:20.000 --> 17:24.000 should then be enforcing this Fabi 2.0, 17:24.000 --> 17:31.000 and what I can then do, or maybe also look into what Fabi and entails, 17:31.000 --> 17:34.000 one thing that I wanted to show, but I forgot. 17:34.000 --> 17:37.000 Now I'm in policy stereo. 17:37.000 --> 17:42.000 For example, when I used to go in this Fabi security profile, 17:42.000 --> 17:44.000 I see a lot of rules that I can actually switch off, 17:44.000 --> 17:46.000 and I can build my own profiles, 17:46.000 --> 17:51.000 maybe I want to gradually introduce different of these checks into my organization, 17:51.000 --> 17:55.000 so they're like, is it 15 different rules? 17:55.000 --> 17:58.000 I can select from I can actually configure them, 17:58.000 --> 18:02.000 and then level up my organization step by step. 18:02.000 --> 18:06.000 And these rules are applied both when you configure new clients in KeyClock, 18:06.000 --> 18:10.000 and they're applied when actually an authorization happens, 18:10.000 --> 18:13.000 and what I will show you now is then just the configuration part, 18:13.000 --> 18:17.000 and please, well, believe me, that is also working with, 18:17.000 --> 18:20.000 like in the runtime part. 18:20.000 --> 18:23.000 So for example, all the URLs need to be HPPS URLs, 18:23.000 --> 18:25.000 otherwise it will not work. 18:25.000 --> 18:28.000 So if then somebody tries to reconfigure the client, 18:28.000 --> 18:30.000 and it minerals the important S from the HTTP, 18:30.000 --> 18:33.000 it will just bail out and say, you can't do that anymore, 18:33.000 --> 18:37.000 because this is consecutive secure client using Fabi 2.0 properly. 18:37.000 --> 18:43.000 Also, if then somebody tries to do some other credentials, 18:43.000 --> 18:45.000 so this is using a giant JWT, 18:45.000 --> 18:48.000 but if I wanted to put it to client ID and secret and say, 18:48.000 --> 18:50.000 but it would then warn me, yes, you want to do it, 18:50.000 --> 18:52.000 but I'll actually it can't be safe, 18:52.000 --> 18:54.000 because that's not proper Fabi 2.0. 18:54.000 --> 18:57.000 So this gives you a great way to enforce these policies 18:57.000 --> 19:01.000 in your organization to make them secure. 19:01.000 --> 19:06.000 So back to this slide, so, so this is what we've seen. 19:06.000 --> 19:09.000 Some of these settings can also be configured on a client level. 19:09.000 --> 19:12.000 For example, you can require TXC on a client, 19:12.000 --> 19:15.000 by just configuring that single client, 19:15.000 --> 19:18.000 but client policies really give you a way 19:18.000 --> 19:21.000 to ensure something across all clients, 19:21.000 --> 19:22.000 or a group of clients, 19:22.000 --> 19:24.000 and there are also more fine grains 19:24.000 --> 19:26.000 and looking into the different, 19:26.000 --> 19:28.000 but also in the configuration part, 19:28.000 --> 19:31.000 but that's a runtime part. 19:31.000 --> 19:33.000 So, all's 2.0. 19:33.000 --> 19:34.000 That's a draft at the moment, 19:34.000 --> 19:36.000 well, it's done probably the, 19:36.000 --> 19:38.000 it's very similar to Fabi 2.0, 19:38.000 --> 19:41.000 but at least no wild card redirects, 19:41.000 --> 19:43.000 also no URL fragments are allowed, 19:44.000 --> 19:46.000 no local house and loopback addresses. 19:46.000 --> 19:48.000 You must take C, no implicit grants, 19:48.000 --> 19:50.000 no resources on a password grant, 19:50.000 --> 19:52.000 so it sounds very similar, 19:52.000 --> 19:54.000 maybe some dell in the detail, 19:54.000 --> 19:56.000 but again, you can use our security profiles 19:56.000 --> 20:00.000 to pick those 2.1 draft as well. 20:00.000 --> 20:06.000 I assume it's going to be arriving sometime this year. 20:06.000 --> 20:08.000 So the question is then, 20:08.000 --> 20:11.000 how to evolve your overall setup in your company, 20:11.000 --> 20:14.000 so it can be like you can pick a security feature 20:14.000 --> 20:16.000 and roll it out to your developers, 20:16.000 --> 20:18.000 you can try to educate your developers 20:18.000 --> 20:19.000 and say, please implement it, 20:19.000 --> 20:21.000 put it on your roadmap 20:21.000 --> 20:23.000 and repeat it for the next thing, 20:23.000 --> 20:25.000 and you always think security is a journey, 20:25.000 --> 20:27.000 but not so happy one, 20:27.000 --> 20:28.000 if you actually want to reinforce it 20:28.000 --> 20:31.000 and it's going to be a bit boring for you. 20:31.000 --> 20:33.000 The other way to do it is, 20:33.000 --> 20:36.000 have you ever heard of brownouts 20:36.000 --> 20:38.000 to speed up to process? 20:38.000 --> 20:40.000 So Wikipedia defines it as a deliberate, 20:40.000 --> 20:43.000 introduction of temporary altitudes to the system, 20:43.000 --> 20:46.000 API of feature that is being faced out. 20:46.000 --> 20:48.000 Sounds like a gimmick. 20:48.000 --> 20:49.000 So what do you do? 20:49.000 --> 20:51.000 If you go to the developers, 20:51.000 --> 20:53.000 explain that the butter best practices are, 20:53.000 --> 20:56.000 then let your IDP enforce it on Monday, 20:56.000 --> 20:58.000 between 9 and 10. 20:58.000 --> 21:01.000 And then set it that then to enforce it permanently. 21:01.000 --> 21:03.000 So people will get a bit upset, 21:03.000 --> 21:05.000 will call the developers and say, 21:05.000 --> 21:06.000 why is my app not working? 21:06.000 --> 21:09.000 And then they will find the figure out why it's not. 21:10.000 --> 21:12.000 So writing emails is only so, 21:12.000 --> 21:15.000 it gets you only so much along the way. 21:15.000 --> 21:18.000 So it's security with a whip, 21:18.000 --> 21:19.000 I would call it, 21:19.000 --> 21:22.000 and you might get some angry developers 21:22.000 --> 21:25.000 but when you have some backing from your security people, 21:25.000 --> 21:27.000 then it's probably a good thing. 21:27.000 --> 21:29.000 Alright, so I'd say, 21:29.000 --> 21:32.000 keeping your application secure is about leveling up, 21:32.000 --> 21:33.000 leveling up your clients, 21:33.000 --> 21:35.000 your IDPs and APIs, 21:36.000 --> 21:38.000 and forcing security policies 21:38.000 --> 21:40.000 and keep your organization aligned with them. 21:40.000 --> 21:41.000 And your IDP, 21:41.000 --> 21:42.000 if you're using Kickstarter, 21:42.000 --> 21:44.000 gives you some great tools to do that. 21:44.000 --> 21:46.000 And if you're successful with that, 21:46.000 --> 21:48.000 and they'll share your successes 21:48.000 --> 21:50.000 and also lessons to learn with the community 21:50.000 --> 21:53.000 because all the yours should get better at all this. 21:53.000 --> 21:56.000 These are the links, including the slides. 21:56.000 --> 21:58.000 We also have some case studies on, 21:58.000 --> 22:00.000 not only about this, 22:00.000 --> 22:02.000 but general case studies on the web page. 22:02.000 --> 22:04.000 Here's the talk from last year, 22:04.000 --> 22:05.000 I'm sorry, 22:05.000 --> 22:06.000 I put the wrong date in here, 22:06.000 --> 22:08.000 but the one where Takashi, 22:08.000 --> 22:10.000 from Hitachi, 22:10.000 --> 22:12.000 and me representing D-pop, 22:12.000 --> 22:13.000 and the security dev room, 22:13.000 --> 22:15.000 Takashi is also the one who put a lot of work 22:15.000 --> 22:17.000 in this far-peas specification 22:17.000 --> 22:19.000 together with the open-mediconic working group, 22:19.000 --> 22:21.000 said it was doing a great job there. 22:21.000 --> 22:23.000 So thank you very much. 22:23.000 --> 22:24.000 That's it. 22:24.000 --> 22:32.000 So we have three minutes, 22:32.000 --> 22:34.000 maybe two questions, 22:34.000 --> 22:37.000 and then let's see how this goes. 22:37.000 --> 22:38.000 One. 22:38.000 --> 22:40.000 Yep, this is a quick remark. 22:40.000 --> 22:41.000 Thank you very much. 22:41.000 --> 22:43.000 Regarding the error messages you have. 22:43.000 --> 22:44.000 Yeah. 22:44.000 --> 22:45.000 Yeah. 22:45.000 --> 22:47.000 Give a good context, 22:47.000 --> 22:49.000 point to the RFC, 22:49.000 --> 22:50.000 point to the documentation 22:51.000 --> 22:53.000 why this is invalid. 22:53.000 --> 22:54.000 Yes. 22:54.000 --> 22:55.000 Yes. 22:55.000 --> 22:58.000 This is complicated stuff. 22:58.000 --> 22:59.000 Yeah. 22:59.000 --> 23:01.000 So the hint from the audience, 23:01.000 --> 23:04.000 the error messages that we're giving are correct, 23:04.000 --> 23:05.000 but not helpful. 23:05.000 --> 23:06.000 And yes, 23:06.000 --> 23:07.000 we're working on that. 23:07.000 --> 23:09.000 I'm talking to some of those. 23:09.000 --> 23:11.000 Actually, it's an open-source project, 23:11.000 --> 23:13.000 and if somebody is wanting to help with that, 23:13.000 --> 23:16.000 I'm happy to approve and review that pull request on that. 23:16.000 --> 23:17.000 Actually, 23:17.000 --> 23:18.000 I'm a maintainer. 23:19.000 --> 23:20.000 Well, I do a pull request. 23:20.000 --> 23:22.000 I have to look for somebody else to do the review. 23:22.000 --> 23:23.000 If you do the pull request, 23:23.000 --> 23:25.000 I can do the review and merge it. 23:25.000 --> 23:27.000 So that's a lot more helpful for me. 23:27.000 --> 23:28.000 Thank you. 23:28.000 --> 23:29.000 But good question. 23:29.000 --> 23:30.000 It's too far, very quick. 23:30.000 --> 23:32.000 Can you see any cases where? 23:32.000 --> 23:33.000 Because obviously, 23:33.000 --> 23:34.000 I have to remember this. 23:34.000 --> 23:35.000 You put the, 23:35.000 --> 23:36.000 you know, 23:36.000 --> 23:37.000 the, 23:37.000 --> 23:38.000 the error messages to test. 23:38.000 --> 23:39.000 Hey, 23:39.000 --> 23:42.000 do you see any scenario where that would be required? 23:42.000 --> 23:43.000 And so like, 23:43.000 --> 23:44.000 you know, 23:44.000 --> 23:45.000 how do you, 23:45.000 --> 23:46.000 how do you take that out? 23:46.000 --> 23:47.000 Just another one. 23:47.000 --> 23:48.000 Yes. 23:48.000 --> 23:49.000 Yes. 23:49.000 --> 23:50.000 Questions? 23:50.000 --> 23:53.000 Is the one point to recommendation on enforcement? 23:53.000 --> 23:54.000 Um, 23:54.000 --> 23:55.000 So about the usurice. 23:55.000 --> 23:56.000 Well, 23:56.000 --> 23:58.000 some people like to have usurice when you do 23:58.000 --> 24:00.000 staving between tenants, 24:00.000 --> 24:01.000 and, 24:01.000 --> 24:02.000 well, 24:02.000 --> 24:04.000 but I do want to use usurice quite in the year olds. 24:04.000 --> 24:05.000 One, 24:05.000 --> 24:06.000 you do tenants. 24:06.000 --> 24:08.000 If you only do one estate in between environments. 24:08.000 --> 24:09.000 Yeah, 24:09.000 --> 24:10.000 but that's proven that it's error prone, 24:10.000 --> 24:12.000 and people who have been finding new posts, 24:12.000 --> 24:14.000 because people when they're not using this while can't 24:14.000 --> 24:15.000 correctly. 24:15.000 --> 24:16.000 So that's why they're insecure. 24:16.000 --> 24:17.000 That's why you need to not use them, 24:17.000 --> 24:19.000 and then you need to reconfigure your roles 24:19.000 --> 24:22.000 to each staging environment in a proper way. 24:22.000 --> 24:23.000 So that's, to say. 24:23.000 --> 24:25.000 And the second question I forgot. 24:25.000 --> 24:26.000 The second question I forgot. 24:26.000 --> 24:27.000 The second question is, 24:27.000 --> 24:28.000 is it enforced to recommend? 24:28.000 --> 24:29.000 Uh, 24:29.000 --> 24:30.000 Well, 24:30.000 --> 24:31.000 the, 24:31.000 --> 24:32.000 TLS point 1.2 or better. 24:32.000 --> 24:34.000 Is that enforced or recommended? 24:34.000 --> 24:35.000 Um, 24:35.000 --> 24:36.000 the, 24:36.000 --> 24:37.000 the, 24:37.000 --> 24:38.000 the, 24:38.000 --> 24:39.000 the, 24:39.000 --> 24:40.000 the, 24:40.000 --> 24:41.000 the, 24:41.000 --> 24:42.000 the, 24:42.000 --> 24:43.000 the, 24:43.000 --> 24:44.000 the, 24:44.000 --> 24:45.000 the, 24:45.000 --> 24:48.000 and maybe you want to do some TLS scanning. 24:48.000 --> 24:49.000 And uh, 24:49.000 --> 24:51.000 uh, 24:51.000 --> 24:53.000 you're environment as well, 24:53.000 --> 24:54.000 so ensure that. 24:54.000 --> 24:55.000 Uh, 24:55.000 --> 24:57.000 maybe we can have some more enforcers on that. 24:57.000 --> 24:59.000 So we're doing about maybe we can talk about that. 24:59.000 --> 25:01.000 How we can enforce it on the kick or clearable. 25:01.000 --> 25:02.000 That you can also like, 25:02.000 --> 25:04.000 or the connection that kick look. 25:04.000 --> 25:05.000 Well, 25:05.000 --> 25:06.000 you can enforce it on kick look. 25:06.000 --> 25:08.000 That we don't accept anything that's worse. 25:08.000 --> 25:09.000 Um, 25:09.000 --> 25:12.000 And we might not enforce it when we call out to others services, 25:12.000 --> 25:14.000 I'm going to be outside for my whole session.