 Okay, so today I'm going to talk about OpenFGA and how it is helping different projects in the community and companies to implement fine-grained authorization for their cloud-native applications. I'm Andres Agar, I'm a product manager at Okta, and I lead the OpenFGA project. So OpenFGA is an authorization system for developers. It's based on a concept called relationship-based access control that you can see as an evolution of role-based access control and attribute-based access control. It's inspired by a research paper that Google published a few years ago where they described how they implemented authorization internally in a way that it was flexible enough to address any of the use cases they have internally and also scale at the scale they need. What I did is we packaged those ideas with a server plus SDKs, APIs and tooling to make it simple for developers to integrate these into your applications. We are currently in the sandbox stage. We are there for a year and a half and the anguishes apply for incubation four days ago, so it's there. And right now, this is surprising when I saw it, but if you list all the projects by number of commits, OpenFGA is in number eight, which is awesome. And so let's try to understand what OpenFGA is. So when you're modeling authorization with OpenFGA, you're going to do two things. You're going to first define what we call an authorization model, where you're going to describe the entities that are relevant when you're making an authorization decision. This is a very simple role-based access control model that is kind of multi-tenant, so the same user can have different roles in different organizations. And then we can say that if you are admin, you can edit the organization details or view them, and if you're a member, you can only view them. So this is kind of the policy that you are defining. You're going to instantiate that policy with data. So we're going to provide OpenFGA the data it needs to use to evaluate the policy. And we're going to do that in the form of what we call relationship tuples. They have this form, user object relationship. And if you see the way it's the colors match, so organization admin is the type. So we're saying that the user, Mary, is related as a member to the specific organization. So a user ID and an organization ID. So in this case, we're saying Mary is a member and Anne is an admin. Okay. With this data that we have in tuples, we are actually going to write that data to FGA, to OpenFGA. In this, here we have shown an example using the Golang SDK, but we have many other SDKs. So we add that data, we call the write method in the Golang SDK, which calls the write API in OpenFGA. And then we're going to store that data in one of the storage providers we support. We have these three, we're going to build more. And after you write the data, in your APIs, whenever you want to know if a user can perform an action on a resource, you're going to call the check API. In this case, I'm asking, can Mary edit details for a specific organization and FGA is on a return yes or no based on the data and the policies you defined? Okay. And in this case, it's going to return false because Mary is a regular member and she cannot edit the organization details. So pretty simple. Now we are not going to build a product to let you build our work that is a problem that is already solved many times, right? The idea of relationship based access control is that I kind of start defining the entities, other entities that map to the specific resources my application has. In this case, a folder and a document. For example, if I want to build a document manage app. So two new types. I can define hierarchy between those entities. For example, the folder belongs to an organization as a parent, which is another folder, the document is in a folder. And when we define permissions, we can start walking that hierarchy. For example, the editor can be the owner of the folder or the admin of the organization that owns the folder. In the editor from the document can be an owner, the owner of the document or the editor from parent, right? So we can start walking that graph. And when we ask if I use a couple of my actions in a resource, we use the model and the samples to answer those questions. This model is still very simple. If you go to GitHub and search for FGA models, there's a lot of companies that are building FGA models and that are way more complex than that one, right? So this is searching in GitHub. And then we have a lot of great developer tooling. So we have an integration resource to your code, lets you edit those models and validate them and run tests. A lot of SDKs and integration with different platforms, a Helm chart, GitHub actions for CLI. So we are really trying to make developers life very easy when implementing authorization. So how OpenFGA is being used today in the community and in the industry? Let's see some examples. Canonical is using OpenFGA in different parts of the Rubuntu ProStack. So in the next version of Ubuntu Pro, if you're running the server, you'll be running OpenFGA. Suplo has a product that is an API gateway that lets you add authentication, analytics, and rate limits to your APIs. And they use OpenFGA to, for each API key they issue, they let you decide which features of Suplo you can use like tunnels, custom domains, API key buckets, monetization buckets. So the permissions are managed with OpenFGA. Stacklock is a company that has a project called Minder, which is an open source project for Suplane, so far Suplane Chain Security, and they have a CLI instead of a UI to manage permissions so you can list the roles, and each time you grant a role, you are writing a tuple in an OpenFGA database. Fiannu is an automated governance platform. They let you define different things that can be run in a build pipeline. You have different, you need to have permissions to add steps to the pipeline. You need to have specific permissions to define what is the green, what is yellow, and what is red, depending on the thresholds you check. And you have to have specific permissions just to override one of those checks and accept the risk of this test that's not running, for example. All of those manage by OpenFGA. OpenObserve is a full stack observability platform, let you define roles. In each role, you can define which resources, like logs, traces, and dashboards you can edit or not. Most that you issue company credit cards and define the different permissions that users have on their budgets. ReadAI lets you produce instant meeting summaries, generate transcripts, actualize some key questions from recordings, and share reports across the team. You can do that with OpenFGA, that's your dialogue. So, if you like this, you can try to start modernizing your authorization at OpenFGA.dev. We'll be in the CNCF project, on Wednesday morning and Thursday afternoon. Thank you very much.