Welcome everybody. I'm here with Johannes Kohlberg. I think I said that right? It's Johannes, right? Yeah. So that's what we say in German, at least, but that, but we're here to talk about identity again. Like this is a very important, it's, it is the key layer, right in. Well, I mean, it's called IAM, isn't it? So identity and access management, and, and I think it's easy to forget periodically that identity is the key to everything, right? And so it's, it's good. We're gonna, we're gonna talk about that today, and hopefully it'll be fun and interesting and go to the next slide.
Just so everybody knows, there are a couple of sort of house cleaning things we need to do. Everybody is muted centrally, and, and, and so there's no, there's no need to worry. We're not listening either, right? But we will run a few polls during the webinar, and we'll discuss that at some point. The, the, the poll questions are based on things that we do over time, and so they're not necessarily directly related to this particular meeting, but, but we'll, we'll talk about 'em anyway. So, and there will be a question and answer session at the end of the webinar. And anyway, you can, you can bring up a question that you want, like it, this is of course recorded, and you can find this in the decks and everything outwards. Okay? So, all right.
First of all, full question number one, how would you best describe the data resilience solutions that you use? Right? And then there's a couple of choices here and, right, so I'll give you a few minutes to think about that. Actually, I don't know that I would pick one of these, but that's fine. So I don't know how much time to give you, I'll give you a few more moments. I, so, so identity systems, let's talk about those, you know, identity systems is, have always bothered me. Like they claim to do things that they can't. It's, you know, I, for Microsoft, they ended up going away from, you know, like, you know, we, we used to call it Azure ad, and, and, and now it's just this flat, you know, data structure, and it's, it's fun, right? Like it works, I guess. But the thing is, is that they don't, they don't actually do identity, you know?
And the same thing with, with ldap, it never, it was just a lookup system for, you know, when Netscape needed, you know, a, a directory for, you know, email and stuff like that, right? So that's where LDAP came from, and SSI and, and ledgers and, and Ds and stuff. Like, what are those? It's, it's, you know, anyway, and then everybody thought they could use a database. I helped a few people do that. You know, it turns out databases don't work that well either. And LLMs what, you know, they, they, they're, they're just a statistical model. They're not really a data system. And so none of these things work, right? For what we need identity to do. Okay? So, and by the way, as is, all right, so in back in 2001, I gave a speech about my report beyond L dap, and people told me afterwards that I killed L Dap. That wasn't quite true, but actually Martin killed it.
So anyway, hopefully you find that funny. But, but Martin came up here later, well, what? Like nine and then finally killed it. But the thing is, is that, yeah, and identity is a weird concept, and it gets pulled in all kinds of directions, and it's not, it's not like normal data, right? It's identity is a very difficult thing to explain, and everybody looks at it from a certain direction, and it's not a single one of those is accurate. It's all of those things. Yeah. So it's easy to think that HR basically knows what identity looks like.
Anyway, that's, that's a, that's an AI created image, by the way. So, but, but yeah, it's a networking explains the world a lot better than, you know, I don't, we talk about relational databases, right? And then there are just tables and stuff, okay? That's not how to describe reality, right? And it, it relationships and context and everything. That's, that's what matters. And so reality looks a lot closer to what the AI just drew up. Anyway, all, so this is, this is a, a presentation that was given by, okay, so the, the, the, actually, this, this goes back a little bit farther than that. So the, the, the never ending language system, or now, right? It goes back to a group of people at Carnegie Mellon, and they ran this thing for like 10, 10 years or so, and they were trying to figure out how knowledge actually works, right?
And it turns out that concepts are all related to each other. And mathematically, that's not all that easy to do. But, but that's, that's basically how understanding works. And it's relational, right? Everything is related. Yeah. Everything we know has some kind of relationship. So, so how does that enter into identity, right? Well, you know, it turns out that even LLMs, as good as they are, they're just, they're essentially what we understand neural networks to be. There's a bunch of nodes and there's a couple of weights and things, and then, you know, suddenly something ends up popping out at the end like, that look cool. And that's what identity looks like, right? It's not, it's not tabular, right? It's not, it is not a normal database, right? And so we need, we need to basically become better at handling identity data, right? That's, that's what we're saying. So, you know, I don't, I don't have to read this slide necessarily to you, but the, but, but graph databases make a lot of sense here, right? Because they're built around, they're, they're built around relationships, you know, and so they can, they can change over time. They can, they can produce all kinds of things that, that basically other databases aren't designed to do.
So this is the closest that we've come to being able to represent identity as it really is, right? And that's, that, that's all I'm saying. So, so I just wanna point out that the way you can tell a really good company from one that's not so good is that, first of all, they have great documentation and support. I, that's pretty much all I need to say, but I'll go, I'll go ahead and, but, but you know, there, there's a lot of other things. I, hon honestly, APIs are important. Scalability, security things, these are all, these are of course, important, but documentation says that they care for you, right? That's, we're here to help you kind of thing. That's, so that's, that's why I put that first. Anyway, now Indy Kite is sponsoring this, and I like that. I think that if you don't know about them, it's a pretty bold move to basically go after the foundation.
Like let's, it's called, you know, it identity literally is the first part of identity and access management, right? But everybody forgets that all the time. You know, it's, it's, it starts with identity and there is a really excellent theme there, right? Right. You might've heard of Forge Rock. Well, can, I guess anyway, that later. But the thing is, is that, yeah, that, that the founding team makes up indie type, right? And you know, there's, there's, there's a lot to do here. Like, there's a lot to be said about getting the foundation, right? And so, you know, I guess that part of what I'm looking at is trying to figure out, you know, AWS so Amazon thinks that they're gonna do a lot of things, you know, and I don't know, like, maybe that'll happen. It's just, but you know, it's just, it's just a matter of getting the product out there, making sure that people, you know, understand what's going on and use it, right? So I think that's, that's kind of it for me at least. But there's another poll question, and I don't, this has to do with AI and et cetera, and less to do with what I just said. But, you know, anyway, that's the poll question. So if you, if you don't mind answering that for us, then, then we can, we can to well, a database. Yeah, because it's a table.
Alright.
All right. So you all probably already know, Mike, you don't know me, so I'm Johannes Goldberg, so you did pronounce it correctly. Mike. I am heading up product and engineering at, at Mite. Like Mike said, we are a fairly new company. I wouldn't say I an identity company necessarily, but the, the crux of our bet is that knowledge graphs applied in the IAM space can, can enable novel use cases and top line cre, value creation and risk mitigation in ways that hasn't been possible before. And that it is crucial to actually provide a proper foundation for AI models. But anyway, to introduce myself briefly, like I said, I'm heading up product engineering here at Indy Kites. I won't spend a lot of time about the company, but we are a couple years old based out of the US and we have about 60 people split roughly down the middle between identity IAM experts, like Mike said, a lot of for drug founders in the company and for drug veterans and the other half being non identity, non IAM backgrounds, but more data engineering, data science, machine learning.
And that also describes me. So I'm not an industry insider here. I instead come from a data ops background and am a data scientist turned product manager. And the really exciting thing about what we are building is marrying data science and machine learning with identity data. So Mike made a lot of relevant points about why we have arrived where we are today in the IM industry. And that one core driver of getting a hold of data and of how to think about identity data is to enable the future generation of products and services, and especially AI powered products within identity.
So this is also not always about the top line identity of the user. So when I say identity, that can be Reed fairly large. We think of identities at as not merely people personal identities, but also devices, sort of like physical machines, cars for example. But also machine learning models and really in an, in a business' ecosystem and identity of anything that produces, consumes and or owns data. And where, where data can also mean more things than just data collected in the IM world, which tends to include things like these human and machine identities, accounts for authentication, access, policies, resources, entitlements, and so on. And in the Siam world, expanding this to include things like consent and preferences and relationships.
But historically, I am and Siam tooling has really only focused on this identity data and the, the SIAM data while limiting the inclusion of, shall I say, business data or data that gives important context but is not typically tied together with the identity data. Like, like accounts and access policies and entitlements and so on. But this information is very important to provide context on the products and services there at the company or customers usage of them, transaction histories, like who's bought what householding streaming data processes within the business. A lot of the context around how these identities of people and things and consumers and producers of data actually interact and behave.
And like in many other industries, I think the realization is dawning here that it doesn't actually make sense to keep all of these data sets totally separate. If you are to build exciting products and services for in your business and in an enterprise setting, you need context, you need to break down silos, but to do so while keeping security intact and protecting privacy and so on. So it's not just about throwing stuff into a glorified data lake, but about contextualizing data across domains. And to also do this on identity data that has either two tended to be quite siloed. And this is not a new idea, really idea in any sense. This has been happening in many other industries already. So we need to do better, I think in the IM space because we're losing out and doing better and innovating on, on the customer experience that we provide as enterprises to our, to all the businesses or to consumers directly innovating on that requires a novel take on how we use and leverage data. And this is especially important I think as the push towards more AI powered products is, is increasing because that requires things that we haven't really done in the IM industry to date.
And there are some, some, some other approaches to borrow inspiration from or tools that we can pretty much directly apply here. Examples here are customer data platforms, CDPs and like customer relationship platforms, some of which already have made headway into significant headway in Im, but I think we can also draw a lot of inspiration from data management and data ops more generally around how we store data and how we groom and curate data to ensure that it's of a sufficient quality. How we ensure availability and trace the lineage so that we can actually trust and have available that data. But crucially also how we unify and provide context. And within imm that context really boils down to identity identities of things and tying things around identities.
So how, how should we do that and how do we do that? There's a very brief, brief history of, of knowledge graphs. The reason they came about was, well they've been around for decades, but the reason they really grew in adoption was for social networks. So Facebook back when it was called that pioneered, pioneered a lot of applications, shall we say, of nor crafts. They didn't necessarily invent all or that much of it, but it was not the first, but it was among the first really big scale commercial usage of knowledge graphs. And it makes perfect sense in social networks because traditional relational databases are great for, for what they're designed for. They are excellent for tabular structured data and they're ex excellent for ensuring that data has consistent quality and structure, but they can be quite onerous and their performance tends to tank when you want to do deep relational queries, ironically, considering the name.
But if you want to do deep nested queries or for those, for those in the audience familiar with sql, just think of the nested subqueries and how quickly performance tanks when you try to get the friend of a friend of a friend. And that is why social networks wanted to use knowledge craft and then got a lot of value out of it. 'cause they're optimized for traversing deep or wide, or both relationships, finding every friend of a friend, of a friend, which would be very expensive in another system. There are other benefits of graphs, but I think what really boils what it really boils down to, if you want to use identity data or if you want to use data napping for building production grade products, services that interact with the real world, meaning you don't just prototype, which actually build products that see the light of day and that customers interact with, it boils down to needing to trust that data, having high availability, easy access to it, and high quality.
And there are a lot of things it can do. And none of these are reinventing the wheel because these have been adopted in other industries. Things like good metadata management and providing context around not only the data that you collect, but around that data. When was it updated? What was the change, the history of changes, the lineage of changes, level of assurance for certain attributes. Like how, how much can you trust this or to provide that type of context, the source of the data, having catalogs of what data exists and what they mean and so on. And that's also what we have built to create an identity centric knowledge graph in enterprises. And to treat that with the proper care of data management and DataOps to make it easily available as a platform for developers to build on and for business people to leverage news.
And it really boils down to trust, trust for the people, the business people that will use that data and act on it. And implicitly trust in terms of being confident in the quality and the availability of it to feed it into AI models and to make products and services on top that relies on that data. All of that requires visibility into the quality of the data and proper curation of it. And this is not just about some pie in the sky theoretical goal of making a glorified identity data lake. It's crucial for enterprises to start operationalized identity data, to treat it carefully, to respect or to, to retain high levels of security and to PR protect privacy, but to really operationalize it, to use it to, to build products and services and to feed AI models and to make better decisions manually if, and that's because the next generations of solutions you wanna build require it. The the manual inefficient processes that we're used to in IAM won't cut it. We're wasting time and money relying on IT teams to deal with siloed data and to manually move things around and to gate keep things. That's why the sea has crept into other spaces, for example, customer data platforms because the traditional siloed manual approach can't keep pace, can't keep pace. So it's, it's unsustainable.
The other is that security really will require it. The, the days of achieving security by sequestering things and having tight manual processes around reading and writing won't cut it anymore because social engineering is a gap. But also because as the business drives more adoption and usage of the data, it will not be feasible to have these obsolete approaches to sequestering and protecting data and to ensuring privacy by essentially making data and available to use. And by 2026, like four fifths of organizations that pursue a 360 degree view or a a full picture view of their customer will abandon efforts because it, it doesn't adhere to data privacy regulations or it relies on obsolete data collection methods or to berate customer trusts because you can't vet the data, which is why it's important to have a solid foundation to build on and to not rely on this siloed spaghetti infrastructure of, of your, and finally, like I've been, like I mentioned, it really is also key for ai.
So one thing is, one thing is that to enable the next generation of products and services that people build, but if you're gonna feed this type of data, identity data into AI models and you're gonna make more personalized experiences, we're gonna make recommendation and recommender engines that actually work personalization, that's the, that the lights users spot anomaly detection for, for risk mitigation for example. Any of those will require structured, well curated, streamlined data products are thinking of identity data as a data product that you can feed into these models and that requires consistency and trust and quality. And that requires a totally different way of having a foundational layer really to operationalize this data.
And a bit of a dense slide here, but I won't go into detail on what we do because this is more about the need for it to motivate the need for it. But I think it's an important paradigm here to consider this as not being in need of ripping and replacing old systems. So as much as I've called things, I've called things obsolete, in some cases there's no need to make, to do a super invasive project. And in general, whether or without indicators where whatever approach you take, there's no need to like rip out all the guts of your technical architecture and your IMM infrastructure. It's more purposeful to, to build, I think, or to adopt a, a layer on top or in between. It's too owners. If all the applications you want to build and the services and products you wanna build, the teams that consume data and the AI models and so on.
If all of those has to deal with the problem of figuring out where to fetch the data and making sure you can trust it and doing all that work, if that happens, if that is needs to, needs to be done by every application, you will get a spaghetti infrastructure of many to many interfaces. And it really puts the burden on the developers and the product people and the business people that develop these new products, services, and applications. Instead, you need a platform in between whether you build one yourself or whether you buy one or whether you do a hi a hybrid, it makes a lot more sense to have a layer in between to extract that data from the silos and put it into context and make it easily available. And this is, this should be something that also plays nicely with other efforts that enterprises have been pursuing.
Many of them are already using Snowflake or as Mike mentioned, AWS or Azure. You often to, to create a data lake that spans the entire organization. It's not about making one more data lake, but it is about, without introducing too many new terms here in the data mesh mentality, that's been gaining traction in a lot of other industries. One key facet is to facilitate different disciplines having different views of how data connects and what it's used for and what it meets instead of forcing everybody to have one, one data model to rule them all to instead facilitate different domains having their own view of things. And that means that it makes sense for IAM and identity data to be one such perspective or one such lens to view an organization's data.
So it, in some, it's really boils down to needing such a platform as that layer on top of which you can stack and build the new products, services, and applications and to feed the ai ai models of tomorrow to really do new value creation. And I mean, operating got more efficiently is one big boon here. So efficiency is definitely a big gain because you can actually operationalize and put to use that data more easily and do the things you already do is more easily. But the other real to me, big benefit is building the products and services and apps that previously just practically weren't possible. Technically might be, but practically aren't. And that is needed to delight customers and, and grow really many business in the next many years. Mike, if you wanna
Yeah, you know, there's a, there's, there are two words that really stuck with me. I, the first one was, you mentioned spaghetti, right? Spa and, and spaghettification is something that black holes do with like stars and stuff. They just rip 'em apart. But do you, do you wanna talk about that a little bit more about what that looks like with identity data? Is that
Yeah, probably easier to illustrate with this. The reason I call it spaghetti infrastructure is, is for every application or service that uses data from other systems that reads data from Siam providers that collate it with data from ACRM platform, combines it maybe with some ERP data, for example, for every app for one application. If I, if I'm to build an application that does that and there is no platform in between, I need to figure out those three integrations and I need to understand where the fetch data from the CRM platform, from the rp, what that stuff means. I need to put it into context. And that's really putting a pretty heavy burden on me as the developer of that new product. And if I am not an expert in any one of those, that's an onerous burden. So it, it both means that the person or the team trying to build the products and services actually use and leverage this data, get a very high burden put on them a burden of expertise and of a risk of screwing up. But also the poor people managing all this flow of data and trying to keep track of where is our sensitive data going, who's using it for what, the lineage of it that becomes an unmanageable spaghetti mess is what I mean, because all those point to point connections essentially constitute a pipeline. But when you have many to many and you start having really a lot of systems silos, storing data and a lot of products and applications and services consuming processing and refining data, you get an a manageable set of integrations.
Yeah, that makes sense. I, it, it, I've been, I've been watching, I don't know if it's available where you are, but I've been watching, you know, Loki, right? And everything gets spaghetti fired by, in, in, in, if you, if you watch that series, it just breaks out like timelines, everyth, it just, everything just basically turns into spaghetti, right? I think that's, that's a really proper illustration for what I think you're trying to say about what happens to identity information, right?
That's, yeah, it gets, gets drawn out, the definitions get stretched, the fidelity is lost, the management becomes impo impossible, and you get these many to many yeah. Mess to try to manage. So Lord knows what it's being used for, who's actually using it, what it means. And the only way that I really retain security and to try to protect previously in that scenario is to silo things, to sequester it. And it's not that anybody's by design said, I wanna make it impossible to use my imm data, but the consequence becomes that it gets really hard to use it. Well
We, we did get a question about, you know, I mean, HR tends to source everything, right? And so how do you feel about that? Is that, is, is HR still kind of like the source of identity data or, you know, where does that, what, what, what would you call the source?
The source can be many, many things and I think that's, I think HR is a logical source of depending on what you deal with. But if it's employee identity data, then certainly, I mean, that's typically the gateway to it, which it will come, but even the employee is also a consumer that data does not necessarily come from HR or an identity can be, can be a device. And it's something I want to consider an identity because it's a thing that has its own set of data it uses and relies on and it produces its own set of data. So it has a semantic meaning as a standalone entity and insofar as it is a protected thing that needs to authenticate itself as itself and is authorized to do certain things and has context around it, it essentially is an identity. And that is quite crucial to structure it that way for especially a machine learning models to have some structure to, to build on.
Does identity kite use AI in that regard? Is that, is that something that you, you already do or are you just helping? Right?
We do.
Yeah.
Yeah. So we already do and we do help people to do it. So we are, we are fundamentally really building a platform and to not get too academic a platform in folksy terms is something you stand on to do something like, literally, and the same applies in the tech stack. So we are essentially providing a toolkit to people to build their own applications and services, but we also use our own toolkit ourselves to build, to build some such products and services. So one of which, for example, is doing knowledge-based access control or authorization on top of a graph. So we facilitate people having, get, getting a contextualized view of identities across their ecosystem in a business. We, that's what we help companies build and we build tooling to help customers build their own AI models and we provide some out of the box. So one example there is on doing authorization, which typically is a binary decision in a, in a policy decision point, you get a yes, more authorized back thumb of thumbs down if the data is stored in a graph can use graph neural networks and embeddings to, and we do to, to look at the similarity between the context around which some subject is trying to access resource.
And you can get a probabilistic score instead of just a deterministic. Yes, according to policy, you're good. You can get a probabilistic like continuous risk score. Like yes, technically you're, you're okay, but the risk here is like 87% because the distance is large. Yeah.
By the way, I'm, I, I need to apologize because I said the name of your company wrong. It's I identity, I I said identity, right? So I'm sorry for that, but that's
No worries.
It's, it's, it's just habitual, right? But I I I, the other question I wanted to ask you was about you, you mentioned the word trust a couple of times, and they, I like that, you know, how, how does, how does identity lead up to trust, right? How, how does that, does, does trust just automatically come out of identity data or, you know, how, how do you, how does that actually work out to be trust in your opinion?
Yeah, I, I use the word, the word trust here as almost as an umbrella term to describe the fact that you can rely on the accuracy and the veracity of what you're looking at, and that, that, that you can, that you can rely on it to make decisions and to, to feed that data into other systems that need it. So I don't think there's, trusting data can arise from many in many ways. One is to have tight curation and to have essentially somebody vet data. And that's typically one of the places people start off, which we do a lot with in the IMM space. I mean, with Im our identity data, right? We have these, we assign levels of assurance to, to some methods. We, we have a, like you give a score to something as, as how reliable it is. You have people dedicated to curate that you limit who can read and write it. That's the way of way of providing, providing confidence to people that rely on the data so that they can essentially subjectively trust it. But the inherent limitations of approaches like that, the manual gatekeeping of it is that you are therefore indirectly by design limiting who can do what with it and limiting how easy it is to use it.
Well, I guess, I guess that part of what I'm after is that, that trust is a concept in computer science that has a lot to do with math, right? Like if you talk about if, if, if you, you know, encryption for example, right? You know, there's, there's certain numbers like, you know, that, you know, you have to basically compute and, and then, but that I don't, I don't, I think that you're talking about social trust and not computer trust, right? Is that,
Yeah, so the, in the context that I was using it, I mean that for example, in the context of AI models, they are only as good as the data they're fed. So while the AI model is not a person that has a subjective notion of trust, whoever designs and operates that model and essentially embeds that into a product, like if you're, if you're automatically accepting or rejecting credit applications based on data that's been fed in about the applicants, then how confident are you as the product manager in embedding AI into that? So in the context I was talking about here, I mean that type of almost social trust yes, in daring to rely on the data, but of course there is more explicit technical meanings to trust as well. I like the
Term daring, daring to rely on the data. That's good. Anyway. Yeah. All right. Well we do have a couple of questions and it's probably time to get to them. Sorry, there, there's some background noise. I hope that doesn't show up, but I, I think that's that, let me look at these questions real fast. Alright, it says, can you address why this should be different for identity? That means AI would be different for identity and access management of all things. Why prioritize this now? I guess, let me rephrase that question a little bit. I think that, I think that I, I think it's a good question, which is to say why, why talk about identity foundation at this point? You know, is it why
At this point in time?
Yeah, yeah, I think, I think that's the question.
Yeah, I'll, well I'm a bit unsure what what they're asking, but I'll, I'll take a stab at it and, and do course correct me, Mike, if, if I'm veering off. So why talk about identity data and having a foundational view of it for AI now? Well, that's a, that could be a macro trend type question. I think a big one is with chat GT and LLMs, I think AI is suddenly on the radar of a lot more people or something feasible. And the push to have AI projects typically is in every board room at the moment. And as long as organizations have had somewhat of a captive audience, or you've been able to build a kind of a low lot of low hanging fruits type products, it's been okay to have a lot of bottlenecks. But I think we're in not just the industry, but in most industries, we're nearing a point now where the push will really be on for people to build AI empowerment into a lot of products that haven't typically seen it. And I don't,
You said, you said build in AI empowerments, right? So, so like, and does an AI have its own identity, right? Or
It could, it absolutely could. So in, in how we view it, they do not, not to make that super philosophical here about, you know, is an AI person. What I mean is, and a machine learning model should probably be considered an identity in the sense in, in a, in a businesses ecosystem in the sense that it is a standalone entity that has some way of authenticating itself as itself. It is, it is authorized to do certain things. It can read and access certain data, it can help with that certain places. It has a lot of context around it. It is essentially an entity just like how a car can be an entity, a car is owned by somebody and it's stored, it is parked in some specific garage. Same applies to ML models. And they, it is important to think of them as, as entities that consume and produce data. Much like people, much like consumers of, of enterprises or employees. They are also entities that produce and consume data. And that is what authorization often boils down to. What data is this person authorized to produce or to consume?
Well, it feels like your model allows for lots of different actors, right? Like that you don't, it doesn't have to be human necessarily. Right? When we talk about identity all times we think of it as being like a human experience, but Yeah. But, but yeah. So but you're talking about it more generally, right? Like it's,
Yeah, and I think that's not to reduce the, the human identity or the personal identity aspect. It's rather to, to broaden the meaning of it. And it's, it's because many of the same principles not only apply but are importantly they're useful in the treatment of data around devices and machines and machine learning models. So that's why I tried to clarify or to be quite clear that the notion of IAM and identity can be broadened. And there's both this proliferation of iot devices that are essentially agents in the physical world. They make decisions based on data and they produce things decisions often. And the same with machine learning models, which are essentially just software versions of the same. They consume data and they output either a decision or they actually act. So agents are no longer just quote, just people agents can also be software and to manage to manage this rapidly growing ecosystem of people and the hardware devices and software applications that consume and produce data requires a novel approach. Otherwise, otherwise you're gonna get left behind 'cause you won't be able to build products and services. Well
This, this is great. This is really great information. I I think that I I don't that I, I I hope this gets noticed, you know, that, that you've thought through it that much, right? It's fantastic. Yeah. So I, I really do appreciate what you're doing there.
Yeah, appreciate that, that whoever wrap the question, I can't, I can't see the q and a, but if that's at all address the question. Well,
I, I don't know how much time we have left. I, I guess how much more? Eight minutes? We've got eight minutes. Okay. Well, I don't know, we could talk about baseball. Are there
More questions in the talk about identification and whether, whether AI is an entity?
Yeah. What do you think, how do you feel about ai? It sounds, by the way, it does sound like you've studied, so are you, do you have a background in AI and machine learning? 'cause it, it, it sounds like maybe you do, right?
Yeah, I did, I did data engineering at, at Amazon first and I got a master's in, in applied computational science at Harvard. So I focused on, I did a graduate degree in ai.
Okay. Okay. Well,
Not IAM so I appreciate you haven't asked the too many hardball questions on the, I am specifically,
We do have, we do have some phenomenal experts on that internally, but my, my journey is, my journey has been to build data ops platforms. So I did that in heavy industry prior to joining indite and I worked on data engineering at Amazon, which is a, a famously data-driven company. So a lot of those same principles that have been brought into other industries a bit earlier, I think it's a que it's a, it's not a question of if it's somebody's gonna do it. And so, and some organizations are gonna adopt those principles and really start to build identity data powered products, not just products that respect.
So a way is basically trying to be there for, let's call it, you know, the, the AI world, right? Like it's, it's, it, it feels like there needs to be some better notion of identity out there than
I think there are two better notion of identity out there coupled with, so there's a couple couple things that that's one and the other is to have a proper platform upon which to stand and build. Otherwise the whole thing will crumble after few applications or you will see what has been the case in a lot of other industries. So for example, in heavy industry, a lot of customers five, 10 years, five years ago mostly tried to do it themselves. It is tempting to, to try and build your own data platform and your own suite of tools upon which you can build your own applications. For example, in, in manufacturing, if you wanna have dashboards telling you when rotating equipment might fail soon or, or how you should tune, tune production to optimize it. Those types of dashboards really operationalize them all of the constitute applications
Actually. So it's, it's good. You mentioned that. If you don't mind going into that just a little further. 'cause we, we actually do have here about examples. Do you, do you have some examples of implementations that you already have in place, like the one you suggested, right? That, that, you know, how, how, how do we use your product, right? And yeah,
The, the example I was just talking about is from my, my previous platform that I built. So that's, that's more to motivate the fact that we are not really, we're not really inventing something totally novel here. We're we are bringing knowledge graphs, which by now is a quite ubiquitous technology and we're bringing data ops and data management principles that are well problem and well-defined best practices from other fields into one that, into Im, which so far hasn't seen I
I like that part. But like is there, is there an example that you can offer that's, yeah, so yeah.
Yes, absolutely. So the, the rot of the equipment thing I was talking about in heavy industry, that's more to motivate the fact that others have done this before and it's about being able to build things like that one such thing that we, that to illustrate this is a customer of ours or let's take insurance not to, to not hand anybody out here. An insurance example here is if you want to, if you want to build a marketplace, an AP marketplace, say to a value chain, if you are an insurance company and you want to provide data that you have on your, on your customers throughout your value chain, you need, for example, to banks or you want to collate data with, with, with banks and trading platforms and and whatnot, whether you give it to them or you collect it from them, you will need to build a holistic view of your customers and what other people are in their family. Like householding them the Netflix problem, problem you will need to sequester properly, which, which bank can read which data on an individual, what do they have to consent to share, who has the right to read and to alter that data, which machine learning models can collate data from multiple partners. All those considerations have
To be your customer on steroids because Yeah,
Yes, in a way it is. Yeah. I, I didn't wanna paint a into the KYC corner, but, but yes.
Right. Well, well, I I so it yeah, I know, I know you're being a little like, so you, you can't mention names or places and things like that, but, but it sounds like you are involved in that kind of problem, right?
Yeah. Another, well, another example to make, perhaps make it a bit more tangible if it helps, is if, if a car manufacturer say, or a plane manufacturer, whoever buys the plane is rarely the one flying it. So if a plane manufacturer, they have a lot of this design data on the planes that they make, they have manufacturing data on what materials are in it, how is it designed, they have maintenance data, what parts have been changed and yeah, what parts have been changed by whom? When they have operational data, like sensors tracking the altitude of this plane mid flight, how is it being handled by different pilots? So you have design and maintenance and operational data being gathered on this essentially flying data platform and they have a complex value chain of people providing maintenance people operating.
You got something like a minute left, so
Losing out.
Yeah. Do you want, do you want to, do you wanna put a finer point on that or do you wanna, like is there
Anything Yeah, so what I'm just saying is that plane is an identity of a thing that's essentially a flying a big flying device. And if, imagine, imagine you are Boeing and you sell planes to somebody who leases it out to somebody else and they have people do maintenance on it. If you wanna sell, if you're Boeing and you wanna sell subscriptions to different data sets on that plane or different fleets of planes, imagine that complex authorization problem. Like Bob is doing maintenance on a specific plane leased by somebody, but he only has access to it because he has bought a subscription to maintenance data and he can only access that data even though he has the general product, he can only access that to planes, to which he's a contractor of somebody who owns it and blah, blah, blah. Like, that's a pretty complex authorization scenario, which is very composite and requires information from non on on much more than just, Bob has a first name and last name coming from Ze and the plane exists. Like, it needs a lot of context across systems, silos, and non identity data. Where are you gonna store that, if not a graph?
That's good. Well, I guess we should probably end it there. I think this is fantastic. I really enjoy what you're doing. It looks like you're looking at identity from a whole new place and yeah, it's about fun that happened. And so
Thank you. Thank you for hosting us, Mike, and thank everybody for, for joining us today. Yeah. You, you didn't see my email at the beginning of deck, but you did, but you did see my name, so if you just Google me, write me up on LinkedIn. Do you have any questions? I'm happy to, happy to chat.
Yeah. Yeah, I think, we'll, I think there will be a lot of chats that happen after this, so. All right. I, I guess that's it, right? Yeah.
Thank you everybody.
