Why Architects Should Rethink Authorizations

Welcome to our KuppingerCole webinar. Why architects should rethink authorizations speakers. Today are Wal du who is vice president of one. Welcome. And me Martin I'm principle Analyst Analyst. This webinar is supported by one before we start some quick housekeeping information. So for audio, you don't need to care about that. This is something which we are controlling, so no need to do anything here. We have a Q and a session by the end of the webinar, but you can enter your questions at any time during the webinar. And the more questions we have the better it is.

So if you have questions, just go to the, go to webinar control panel. Usually it's right out of your screen, enter your question and we will try to pick it up if time lows, otherwise we will follow up. After the webinar directly, we will record the webinar and we will also provide a slide X to you as PDF. They will be available for downloads usually today after the webinar. And finally there will be polls. We will run. I think today we plan to, we intend to do four pulses and hopefully a lot of you will participate in these polls.

The more answers we get, the more wallet and the more interesting the results are. And that's what, what we will start with before we then have a look at the agenda. So as for most of our webinars, we work with a agenda which split into three parts. In the first part, I'll look at some aspects of the future identity management. I'll specifically look at policies and authorization and at just in time access. And the second part, then what we'll talk about, why architects should res rethink authorization, and then already mentioned will go into the Q and a session.

And again, if there are any questions you have on things we talk about or things you're missing in the webinar where you need information about around the subject of today's webinar, don't hesitate to enter that question so that we have a lot of questions for the Q and a session. So when we look at this topic of today, then I'd like to start with something which is about, we, we need to take a, a broader perspective from what I believe on identity and access management. So we need to, to look at it as a more comprehensive manner.

What I mean by this is that identity management takes a different role than it has done in the past. So in the past, it was a lot of about workforce identity about I HAA, where we manage access entitlements for our workforce, mainly about privilege access management is about also the, the overall access management like us education Federation.

We have, when we look at the graphic way more types of identities today. So the types of identities are sort of everything. This is our keeping call, identity fabric concept. We talked and have written about quite quite a lot in the past three or four years, but it's not just the workforce. It's partners, customers, consumers, but also non-human identities. And we also need to manage access to way broader set of applications and, and services than we ever did before. But what is maybe, maybe even more important in that context is that we also need to enable the access from digital services.

So when we look at the upper part and I expanded it a little here, then, then one of the important things is traditionally, we looked at identity management and we manage applications. We manage the accounts and the entitlements and the access, but nowadays it's not just managing assess service, managing a legacy application, which is the bottom of the graphic or something else. It's about enabling digital services to consume identity management. There are comprehensive solutions, more must deliver identity services for digital service, through an identity API layer as we call it.

And that is relevant for everything it's administration. Yes. So enabling the digital service to register for instance, to uses, enable the service to request an authentication, to build on authentication service, right. Also to think, but also to authorization. So these services must be abled to consume authorization to say, okay, is this user is Martin entitled to do that? And that is something which is very flip, the direction of, of what we do in identity management. We're not just going out managing services.

We are receiving incoming requests where the systems request something from the identity management system. And this is from my perspective, a very important paradigm shift, which has to do a lot with the subject of today's webinars, because webinar, because it's about enabling that, enabling our identity management to a level where it can serve these requests, where it provides an identity API layer and where it supports ostracization.

The second, when we talk about where's identity management heading the second very important thing I see here is there, there quite a lot, but this is one of which shows a very close to the subject of today's webinar that is policy based and policies are the core of what we do in the future of identity management. They are that new policy based concept. So in access management, when you look at policies around authentication, so is someone allowed to authenticate or not policies that also take the context into account. This is a lot which is done based on policies.

They are also, if you take firewall rules, they are policies exact there's older standard. What in fact, the policy standard and policy based standard, and what we need to do is we need to think broad, good thing. And policies is policies are so easy to understand. They are always, they have always the same structure, subject, and action, and object and constraint.

Martin subject is allowed action allowed to access fact the action that file from his workplace constraint, the last one, but it's always the same thing, same structure you'll find in the file or the same structure you are using in daily life. Child. Don't touch, not open. It's a sort of a policy policies are easy and everyone also business can easily describe policies. If you ask people about their, their policies. So what are people allowed to do are not allowed to do in a certain department. They can easily describe it. If you ask them for business roles, things get tricky.

Cause business roles, aren't very artificial concept. So what can we do with policies? We can do better roles and better and lesser re-certification. So we can really improve these areas. We can automate static entitlements if we do it right. So vendors could use policies to derive static entitlements from that, and automatically updated can be done. Unfortunately, isn't yet done by, by I am tools, but something, I, I still hope that some vendors will pick up this idea and start implementing it.

We use it already quite a lot for adaptive authentication for authentication in a, in a risk and, and context where we say, okay, depending on the risk, depending on the context, we have a policy that defines what's allowed or not. We use it for dynamic authorization. That is what exactly, and where we see quite a lot of evolution these days with new concepts, new standards, new capabilities here. And this will be one of the main subjects surely in our today's webinar. And it is about zero trust.

So if you ever looked at a list zero trust model, then, then you'll see that policies are at the very core of missed zero trust because you only can do a continuous verification. This is there's always verified, don't trust or way, right? You can only do that based on policy. You verify with the policy, this is what is happening here as well. So policies are a, a foundation of everything we do in modern identity access management. So we need to think more policies. We need to do more with policies. And part of that is authorization. So we should take a very stronger focus on authorization.

Who's allowed to do what it is when we take our call, reference architecture, your, our identity management reference architecture, which we just recently have updated by the way. And it's well described in the new advisory note. So when I sum out this authorization part, then we see that policy based access management and trust in time access are two of the, the main areas. And we need to do more here.

And yes, it's not new. You can argue, you know, 1976, IBM released R F the resource access control facility, which in some way was something which was about authorization for source success. So the idea is not new, but we need to do it now better, a more dynamic moving away from static entitlements toward and authorization at runtime, specifically for the staff, we build new. It's easy to do when we build new digital services, because, and that is what, what we need to do to be successful in business.

There, we can really do it and we can benefit from it because we will speed up the time to deliver digital services to the market. It's about time to value here. This is a clear business drive or business impact, a positive one we have if we do that, right, because, and that brings us back to policies, authorization builds on policies. It also can help with a lot of legacy when you have gateways or so at the end for authentication an authentication server, nothing else on the gateway doing that, where you implement this. And as I already said, it's cornerstone of zero trust.

So for this trust and time topic, this is one of the things which then come into play automatically. It could, could simply say static entitlements are bad. That is probably the easiest way to describe it. It's a little bit of a bold statement.

Yes, I agreed. But in the end, it's exactly the point. Static entitlements. They are causing security risk. They are hard to manage, look at all the libraries, recertification stuff. So static entitlements cause problems. And when we live in the world of, of agile it and where six change barrier very quickly, then static entitlements are not the right way to do things anymore. We need to get rid of that. That's only, we only can do that when we shift towards policy based approaches because of a policy based approach.

And when we look at the, the upper part, the sort of the, the top level of the top of the three graphics, that's about uses request, sending access requests when authorization system, maybe also getting authenticated here where policy engine looks at us. And if the policy engine says, yes, then the service trusts the system. This is where the digital service at the end then works. So the user comes from digital services, requests and access, and that is what is happening here. This is where we can work against such a system.

We also could provision entitlements and deprovision entitlements more or less, not fully real time, but when required making this way more short lift or what we see for instance, in ed access management, or already quite quite frequently is, are use of ephemeral certificates. So very short lift certificates that only give access for a very short period of time based on the policy, sort of if the policy says yes, then the certificate is issued, but very short lift. And so the next time the user comes back, it says, okay, you need to check the policy again.

So we do this always verify we don't trust someone. Okay, well, you have been here. You probably are a good one. It is a different approach. If we need to move forward to whats approach that are dynamic, that are policy based that are trusted time, because if you want to have an agile it, if you want to surf the digital services, that the, the world of infrastructure is a service of today and all this stuff, then it only will work if we make brokers. These and that is where I hand over to work. When only I have is a hammer. Everything looks like a nail. This is from my point of view.

So true for the topic that we currently discuss in this webinar, because we, in the identity industry we've been using role-based access control to solve any type of authorization challenges that we came across. But the issue with role-based access control is that it has been designed for hierarchies. People get rolled, cause they are part of a certain hierarchy. And this is now part of the challenge because digital services of today, they're no longer built for people inside of an organization, but they're more and more built for people outside of the organization.

External users and external users can be, can have different forms. So you can have consumers that are part of a household or family or that, or a member of a sports club or an interest group. But you can also have professionals that are basically delivering services as part of a business partner or working as a freelancer or being a member of a, of a franchising network or, or a deal network.

So when we deal with authorizations, we really have to focus on these external users first because they, they, there, we see new needs, new characteristics and new challenges, new challenges to be resolved. And if we want to rethink how that we currently do authorizations, we also have to take some time to evaluate what we currently have.

How do we deal today with authorizations like the majority of, of, of the world today, if we look at established vendors and identity and access management, there is typically a focus on business users, employees, while if you want to try, if you want to apply the same technologies for consumers and B2B collaboration, they, these technologies suffer from scale and complexity.

So dealing with dealer networks of, or, or, or similar things at certain scale, which is something else than just a role and hierarchy Federation was a, a very interesting topic that a very interesting technology that we have been using in the past to establish enterprise to enterprise trust. And it worked very well for a limited number of enterprises. But if you want to scale up to one hundreds or thousands of business partners that you work with Federation, doesn't do it trick anymore.

So we need to have a decentralized mechanism where there is much more emphasis on delegation, delegation of, of administration to different teams, different different user groups. Traditionally up developers also focused too often on one single user. One up was built with one single user in mind. What we see today is that, that people that built digital services much more focused on ecosystems. So people want to share digital assets. People want to collaborate on a digital platform.

And so there is not one user that will use a service, but there is an ecosystem that is using a service and our authorization mechanism, authorization technology needs to adopt this new reality. And what we see today is with these single user ops too often use it, share digital assets by sharing their password.

Think, think Netflix, for instance, if I've got a net Netflix account, and I want to share my Netflix account with my family members, what do I do? I share my password with my family members. We think that the family should be considered as an ecosystem where each and every individual in the family should have its own proper account. Right? If we then move a little bit in, into the non-functional perspective, we see that today authorizations or often still embedded in native codes, and that works pretty well in mono environments where you've got applications.

But if you are scaling up to a network of distributed microservices, it becomes very challenging to build code in each and every microservice to deal with authorizations. So externalizing authorizations is almost like a, a prerequisite, if you want to start using a microservices architecture. And so overall, we see that there's somewhere a common pattern in managing authorizations for these external users. And that makes it very valuable to start using out of the box technology because the out of the box technology is, is built by experts and is built to scale.

And so you can benefit from it by basically reusing patterns that have been, have been coded before. And I think that we are kind on kind on the same journey then what authentication technology did go through like a decade ago, where we went from and, and it took us like 10 years to go from a world where companies typically did build their in house authentication solution, where we are today in a saturation where each and every company that is developing digital services will buy and off the shelf hardened authentication platform.

And so if I may quote some, some, some smart people that are on stage in London a couple of weeks ago, it's the decade of the authorizations. So we dealt with the authentication piece.

Now we, as the industry have to deal with the authorization piece and that fully I fully in line with Martin on that. So we learned that identity has become a very volatile thing quickly.

So if, if identity is, is something that's, that's not very stable, comparing it with a role in an enterprise role in an enterprise is something that you will have for years. Having access to a digital insurance claim is only a matter of days, maybe hours that, that you are allowed to, to do a certain transaction and an insurance claim. So there is a certain continuous change that is happening on the level of identity. And so in order to come to an identity, first security mechanism, you need to have policies that determine in real time what user is allowed to do.

And that's very, very much in line with what, what Martin said earlier. And so indeed policies have been used in, in security landscape for, for quite a while, going back in, not to the RAAF timeframe, but to the networking world where you had a 93, you had a standard called network access control was, which was based on policies to determine whether an a T P I P package was allowed or not allowed to go through a certain gateway. And then indeed early 2000, we had the, the Z standard that, that was published together with a number of companies that started implementing it.

And standard did bring us a very strong reference architecture, which I definitely would recommend to read as well. But the syntax to implement was a little bit hard and didn't, didn't adopt well in the developer community. And now very recently, 2018, 2019, we see, we saw that the developer community took up, took up and, and saw a lot of interest in one particular project called the open policy agent project OPPA, which is promoting again a policy based authorization mechanism for, for building applications. But there is one thing that I, that, that I want to add in this schema.

And that is the relationships between users and relationships between users and things and certain objects. And that is because this extra dimension relationships tells something about the context of user. It tells something about the ecosystem about the community, where the user is, is part of, and the combination of these three turns out to be a very effective and a very pragmatic mechanism to implement an identify first security mechanism. So going a little bit more into the details, looking from an, from an architectural point of view, how can we get rid of these bad static entitlements?

Right? So what you likely recognize on top of here is the one of the out authorization grants, where you've got a user who interacts with user agent and client, and at there end, they now need access to features and data from a, from a resource server at the back end happens. If you start to use the access token between client and resource as a transport mechanism to transport an authorization decision from the decision engine to resource server.

So it's, it's like the MFR certificates that Martin refer to this is, this is an authorization that is backed into, into a Jo token or something similar that, and that is validated in real time. And so in order to include search authorization decision in a token, we need, of course, the token issuer that that's not, not that that easy that's, that's easy part, but we, we also need a decision engine. The decision engine will take an authorization decision at the moment that the user will request a new, new access token. So there needs to be policies that, that, that need to be administered.

And that's the, the policy administration point. And these policies will determine which information elements will be included in the evaluation. And so in our platform, there are three different information sources that are all ready to be used in an, in an authorization policy. One of them is the identity store, which you do know from which contains the, the, the identity profile. The second one is everything linked to consent. So if a user gives a consent, this is some, this is a record that distorted in the, the life cycle of, of consent management platform.

But by not only storing the consent as a record, but also using that consent record as part of an authorization decision, we actually turned consent management into consent enforcement. If user didn't give the proper consent, you will not be able to use a certain service, feels like a dream for a lot of data, privacy officers.

And then the third information endpoint is the relationships graph database, which contains the representation of relationships between users and users and things, and it's graph database, meaning that it's like an infinite cloud of, of different data elements that are interconnected.

And these relationships can be self-managed by people, users on top, but can also originate from alternative sources that basically say that there is a new relationship that needs Now, in order to consume this focusing a little bit more on the resource, you can build your own logic to, to interpret these jot tokens written authorization decision.

What you also can do is use out of the box components that basically do that for you can be an API gateway, can be an agent that you basically embed in your resource server, who will be used to interpret the information from the jobs and take some additional fine grained authorization decisions if you want. And it also brings me to a certain misconception that we very often hear. If you talk about policy based authorizations, very often people think that there can only be one decision endpoint and the change from the user to the resource.

My point of view is that that that's a bit too limited because you can have multiple decision endpoints that basically communicate with each other, like in this case, there is one decision engine that basically determines what the content of a token can be. And that can be another decision engine that competes the token and, and takes, takes one decision. The decision one step further, for instance, and it's all about granularity. For instance, this decision engine can determine whether user is allowed to act on behalf of an other user for a particular insurance claim.

While this decision engine will determine whether a particular field on a particular form is read only or read, write for that particular user. So it's another level of granularity. And if you want to externalize authorizations, you have to deal with the question of granularity. And that's more, more like the, the, the, the architectural nightmare in these type of designs where we, where we are happy to help.

Of course, looking a little bit forward in, in our roadmap as, as a product company, is that we also want to make it easy to administer policies for decision endpoints that are outside of the externalized authorizations platform, An alternative to using the job token and, and as a transport mechanism for an authorization decision is decision endpoint also very similar to the Zal reference architecture, where the resource server will ask for a decision from the decision engine via a back to back protocol. And there you, would've the resource server that says subject action resource context.

These are the four different elements give me and allow, or give me and I, and, and give me some additional contextual elements if needed. And so this is, I would see as a reference architecture to start using externalized authorizations and by externalizing authorizations, we can generate a number of business benefits. So number one is a faster go to market. Also mentioned already by by Martin. So by separating policy management from application lifecycle, we, we make it easier to change policies without changing codes.

And so both live separate policies are, are distributed amongst multiple microservices. So overall time, time to market will be reduced. We also give the user to better user experience, because if we use relationships, we basically rely on a number of, of habits that use yourself from social networks. It is due to LinkedIn and a number of social networks that we, we all as end users understand what the first line, the second line and a third line connection means.

And so using this type of vocabulary and using these type of mechanisms to deal with authorizations makes it easy for not use it to understand. And third last but not least having an externalized authorizations platform in your architectural landscape also improves consistency of authorizations. Consistency comes with, be consistency comes with better security. And cause we get a more streamlined approach and streamlined enforcement of different authorization policies moving on, making, making it all a little bit more concrete with, with the use case or with an example.

And it, it is a case from supply chain because logistics and and supply chain management delivery of goods today is, is like a schoolbook example of B2B complexity. It's B2B complexity at scale, because there are so many different companies and parties involved to get the little packages delivered to your doorstep after that you ordered something online.

And so the, for those that don't, didn't, didn't see the term before mom and pop shops are basically is word that is used in the logistics to refer to small companies, run by husband and wife, less than five employees, less than 10 employees, a couple of drugs, couple of drivers. And in this example, the, the use case actually starts with John, who is the contract owner, and he can assign a new contract for a new delivery or, or what have you to Bob's company. And Bob's company now will take care of, of the execution of that contract.

Now, if you look at Bob's comp company, we see how the ecosystem around that company starts to unfold. You've got Bob who is the owner of that company. You've got Brian who is a driver for that company that you can also be a driver for other companies as well. You've got Mary who takes care of the human resources part of, of Bob's company. And since that Mary and Bob are married, Mary is also a legal representative of Bob. And this is, this is kind of real world how, how things can, can look like. And so before that, you can actually start defining policies.

We first want to define a domain model. And what you see here is a, is a, is a snippet of our graphical configuration tool, where we built a domain model before that we can start applying policies. And the domain model starts by defying the different elements that will be managed in, in, in a graph database.

So, first of all, there are a number of users, John Bob, Mary Bryan, they're all from the same note type. So it's all from the same type called use it. And that's why you see one note type called use it. And next to that, there is also something called contracts because it's, it's another static object.

That is, that is part of the, of, of the craft network. Third object is company. And so what you basically see is that with these three different node types, there we start building, we, we start documenting how the domain model looks like. And in between these different node types, there are different relationship types where you can see that there can be one relationship type or multiple relationship types depending on, on what is needed. And what's also special is that you see some relationship types that go from one node type to the same note type.

In this case, the user can be illegal representative of another user. And this illustrates the infinite I, or the internet looping internet nesting that you can build in, in such a, such a database. So Bringing this back a little bit higher in, in, in, from, from an higher point of view, by introducing these new new capabilities, you basically can enable a number of new use use cases.

So if your technology landscape is using a number of microservices and, and you are looking forward to your future with more microservices and, or your business depends on relationships that are self-managed, or, or that are dependent on from sources, you likely have somewhere a case to, to build and, and to use similar technology than, than, than this space about insurance products that you can or use cases where you've on, where the parent gives consent on behalf of a minor or where you want to implement parental control. Also data stewardship.

I want to share my data and, and I give somebody else that you would stewardship on my data, but also in the B2B environment where, where we see use cases around delegated user and access administration think broker networks in the insurance industry or dealer networks in, in automotive, but also franchising scheme as in, in retail, but, and also more the traditional subcontractor agreements as well. What you also see in the B2B use cases is power of attorney.

So I, I want to give power of attorney to one of, one of the employees, one of the colleagues, and I want to have a certain independency in doing that. That being said, I hope that you now have somewhere an idea of how a new tool in your toolbox toolbox could look like next to the hammer. There are a lot of different tools that you need in your toolbox. The thing is that, that we, as a technology company, we only make tools and we are, we want to get, we be surprised by the stories and the ideas that, that you have on how that you can use these tools in your real, real experiences.

And as I earlier, the more questions you entered, the more interesting and more lively this will be, I think it is a complex subject. And so there could be quite some questions, hopefully. And I I'd like to start with one question we, we already have here, which is you presented two options to work with external externalized authorizations, tokens versus decision and points, how to choose. That's a very valid question. It's it's again, a balancing act.

The, the, the answer depends. So it's balancing act between latency and security. So a token has a certain life cycle, meaning that once that the token has been issued during the life cycle of the token, you can't change the authorization decision.

So you, you, your penalty is security, but building platforms with tokens is, is very beneficial for latency because adding a token into other requests, doesn't add any latency. While if you have a decision endpoint, you can have more often a check towards the authorization server, but there is always a penalty on latency and performance because you have to call an external system. So it's really balancing between when, when do we do which mechanism, what would be best.

So that, that would be my, my short answer. Okay. Thank you. And maybe at that point, we have a, we have a quick look at Paul and you, you brought up this, the sub of whether OS two already is adopted, or is being adopted for business critical applications. And I quickly share, share the results of the poll.

And so, so I think one interesting thing is the, I don't know, part of the answer. And then it's, it's quite a mix between yes. Marginally or no, and relatively few astonishing, relatively few, which say it's really for the maturity of applications.

So I, I, I find it interesting to see, I would have expected, I would say higher oldest two adoption already, but hopefully we, we make brokers on that. In the meantime, we got two, two more new questions in here. The first one is it seems that sort of the, the effort for describing the ecosystem for a relationship for, for a new customer or winter, that could, that could be very high, that the effort of describing this, these relationships, do you find this to be, so I hope I got this question, right. So the question is about how complex is it to get started?

I think you brought up this, this, you described the relationships, you created all this sort of crafting at the end of the day. You, you did so. So how is the practical experience here? So it's something that, that anyhow needs to be done because it's part of analyzing your business business environment and analyzing your, your business needs.

So whether you would build a similar platform in, in your own backend system, or whether you would externalize authorizations and, and put it and model it somewhere else, I think the effort to analyze the, the reality is very similar by using a certain pattern. I think that it even becomes easier to, to, to start modeling it. If you already have a certain number of blueprints that reflect, for instance, a family construct, or for instance, delegated admin construct.

So the, I, I would argue actually the opposite by, by using a number of, of, of blueprints. You can actually speed up the, the effort and reduce complexity to, to, to get started. And then on top of that, if you get started with, with a certain model and you, and you want to change that afterwards, that's also something which is, which is feasible and, and, and also supported and, and seen in practice as well.

Okay, got it. So, so the next question I have here is we run a kind of a web Porwal for offering consuming a service management and accessing the invoices. The Porwal is used by small companies. Several people need access to one or more of these use cases.

Like, as I said, ordering or managing or looking at invoice, we do that with roles. What would be the benefit of policy based access here? The short answer would be self serviceability so that the one person, or depending, depending on the relationship of one user with particular contact, you can grant that person. Also the ability to share that contract with other people.

Yeah, I would would add, look at these types of use cases. The point is always, you have so to speak different roles, which is one dimension, and you have the customers, and maybe you even have the delegation aspects, which really leave out. And the point is that we at the end of the day would say, you can manage, but only for that. And once you start, and even moving to delegation use cases, it gets way more complex because there might be someone who manages for a couple of small companies. And at the end of the day to do it with policies, it means you basically have very few policies.

At least if, if at also you have a few, but it will be very few policies because the, for instance, the organization is sort of a constrained where you say, okay, you are allowed to manage, but only for, and then it's still just one policy where you can handle even the delegation use case with as long as the database says, who is authorized to do that. And this means that you end up with a very simplistic approach here, and this is where I believe there's a definitely very significant potential of using policies.

Yeah, I agree in that. And, and so the, the example that you mentioned, and the one user that is connected to multiple companies, for instance, that is something that is very hard to build in roles. Exactly. And I think, I think know these are very common use cases. So think about just when I look at this typical, you have a sales team that sales team, for instance, a science, certain zip code areas to certain zip code areas, then you can create a number of roles or one policy. And one policy would just consume the zip code area.

Someone is assigned to and decide what people can see way simpler, also way simpler from, from the entire management of entitlements. And I think this is from my perspective where, where, where, where, where policies start becoming very interesting, because we can, can take multiple dimensions. And instead of ending with a role explosion, which comes from multiplying sort of certain dimensions, we end up with still very simple policies. And I think this also applies from my perspective to that use case described.

So, so maybe let's pick one more polar salt where don't have much time anymore. And I think this is, this is an interesting one, because it is about, do you already have use cases? And I think very few answers, no, we don't have them, but half of the people answering the poll that we are not sure yet. And I think we still have, from my perspective to do a lot of education here, because there there's a there's from my perspective, and that's why I'm bridging this for, I don't know, decades probably.

There's a huge potential in that I remember, I think back in 2007, 15 years ago, I wrote a report on application security infrastructures. So how can you work with this identity APIs? How can you externalize that?

So, yes, we still need to educate, but I, I think the simple point is when you compare it, for instance, to roles and other things, there's at least if at all, there's little where roles are better than policies, simply speaking. Okay. I think we are, we are done with the questions and at least to some of the selves, that's where I want to say. Thank you. Thank you to all the attends of this webinar. Thank you to all one, welcome for supporting it. Thank you to your work for you, presentations and your insights and hope to see you all back in one of our upcoming events soon. Thank you.