Good session today here in the auditorium of the 2016 EIC. I have the pleasure to introduce a keynote panel with a number of famous people. And I would like to call him on stage one by one, please. Welcome Eve Mala, Jerry Gable. He Engler Dan bloom and Martin Kuppinger. Thank you so much, lady and gentlemen for joining for his keynote, as you can see in some, in some countries of the world, five o'clock is tea time, not here. B Bavaria it's miracle time.
Yeah. I mean, how are aren't you playing the blockchain drinking game, right? Drink every time I say blockchain. You mean you're not twice
Right there. Oh yeah.
Okay.
Okay. I would like just to introduce you very quickly with your current role, because probably nobody, not, not all people here in the room have followed your LinkedIn profile in the last month or so
I'm Eve mailer I'm with, for rock VP of innovation and emerging technology, driving privacy and consent innovation.
I'm Jerry Gable with Matics manager for the us team, and we focus on externalized authorization, dynamic authorization systems.
I'm Ian Glaser, senior director for identity at Salesforce.
I'm Daniel bloom, senior Analyst Analyst with Kuppinger call. I just signed up with Martin last week, looking forward to being back in the Analyst role, writing some interesting reports for everyone and continuing to do my consulting work through security architects partners, which I've been working on for the past year and a half.
Okay. I'm Martin Kuppinger, I'm one of the hundreds of co AOL acting as a principal Analyst.
Thank you so much. So next challenge for you guys is to answer the question that Martin except Martin, maybe we'll see at the end, what he's going to comment on it. He has actually challenged or or asked for in his presentation is keynote earlier today. Namely, what is the role of identity in the digital transformation Eve would like
You look at me? Oh, well I thought of a few roles. It can obviously be a tool for security protection, security and privacy protection. It can be the outcome of surveillance, including corporate surveillance for lots of kinds of intelligence, customer intelligence, fraud, intelligence, and others. And it can form the foundation for our relationship business to customer relationship, a business to end user relationship. So that's some thoughts there.
Okay.
Yeah. When I think of digital transformation, I think of taking a lot of the friction out of business processes and certainly identity propagation across different channels of communication from an organization to their customers or partners is a very important aspect and identity plays a key role there.
You know, I think from my perspective, the, the role is simple. It's crucial in, in the sense that every transaction is an identity transaction, right? Because every business process has to have the context of identity brings to it in order to both integrate it and make it valuable.
I thought Mia, the speaker from world bank said it very well. Identity is all about access and the opportunity to have a prosperous life. And so as enterprises, we can help our customers do that through managing their identity correctly. And as enterprises also, we can use that to enable our employees to be productive.
So I, I would trust say, it's the glue, it's the glue between the humans, the things, the devices, which makes all the transformation
Work.
So let's, let's, let's think about with IOT for a moment in that respect, since you said that this, these three areas will convert over time and there's one, one it silo, or today silo probably no longer, not so long silo, I would say by the way, folks, if you want to join into the discussion, use the usual tool, use the app and we will make sure it was going to display front and we will see it here as well, so that we can respond to your questions. But to coming back tot, if we see if, if, if I remember the presentation earlier today from Andre also questioning that we will drive ourselves no longer than 10 years, maybe or cars. So there will be devices that talk to devices and people will no longer make any decisions. So there will be no people transaction or do I miss something in that picture?
Yeah. Yeah. Well, you totally miss something. It doesn't matter what the device is. It doesn't matter what the thing is because behind everything behind every connected device, there's a customer, there's a human in every situation and that's the individual we're trying to serve. The thing, the connected device is just yet another vehicle for connection point on along, which we have to serve the customer and understand who that customer is.
Yeah. And I, I think, you know, if you take the connected vehicle part, so the thing doesn't know where to drive the human knows the thing might know the better way to come from a to B, but the idea. So it might even know that that truck is better than that shop, but the, the point that someone wants to make them move in some way, this is always something which comes from the human. So this might help us to find better ways that might help us to find better shops, which have the better offers okay. At that point of time, or which provide a better fee to the provider of the service, whatever else. But the human is in that equation. Anyway,
It's, you know, I'm, I'm gonna push back a little bit on that. I can see that you want to as well, perhaps I don't know. Can you do that as a moderator? I guess you can. No, maybe I'll do it for you. There's a lot of work that's been done on the concept of identity relationship management over the years. And there's a lot of identity relationships between people, between people and things between things and things. And a lot of times those relationships can reflect a lot of layers of intent intentionality. So, you know, some of the work that I don't know we've been doing in our labs includes what you can think of as authorization intention, by a human to direct what things should do. And those layers start to look like the things are operating autonomously, even though, you know, they're not at some point, even if there's AI in them, but there's, there's some abstractness to the authorization.
So, I mean, let's say somebody marries into your family and what you wanna do is say, look, they've, there's a new relationship. A marriage has happened. And therefore that new person in our family gets access to the smart blender and the smart refrigerator and the smart light switches. It's impractical to have them, you know, have somebody set policies one by one by one by one by one, by one by one, there's a lot of things you'd have to do. And so having those things act autonomously to accept that person into those things lives, I'm now, you know, anthropomorphizing a lot. It, it would be a lot of effort to, you know, have to have those relationships set up, you know, one by one. But the so identity relationship management, I think can accommodate a world of a lot of things. Even if there's very few humans, I think it should.
Okay. Anyone to comment?
Well, I've read some interesting things about identity, relationship management. And I second Eve's notion that a lot of it needs to be put under the control of the individual that the things are serving because only they can know how they want to manage them. But at the same time, you would have to work towards simplicity in the interface so that they can do that without too much cognitive overload. Another factor to consider is that internet of things is very different depending on what type of business you're in. If you're selling to businesses rather than individuals, the things that they have to deal with, maybe oil drilling, rigs and trucks and pipelines and things like that. And those have specialized interfaces and sensors that have to be dealt with. And there may be some significant integration and scalability issues. So you may be working with as identity vendors in the audience. You may be working with aggregator gateways that are actually handling those things sensibly for you. And when you look at the internet of everything first, billions, then maybe a trillion before too long, I think the things will start to acquire enough memory and processing power to handle the security SSL PS. But I'm not sure that identity management, as we've implemented it today, can scale to talk to all those things. And so that will be one of the reasons why we depend on these gateways for a long time.
Yeah. Dan, to, to first point there about discussing IOT in the context of some particular business, that makes a lot more sense than talking about it in the abstract. You know, there could be user centered activities, you know, like a relationship management, but some of the interesting examples I've been, I've been reading about or talking about are like in the healthcare world, if I have different kinds of medical devices implanted in me, you know, if I have a cardiac condition or diabetes condition and it's sending data, you know, to some lab service or what have you, maybe I need access to this data so I can adjust some medicines or they're monitoring me remotely or something like that. So there's connectivity of the devices themselves to, you know, receiving stations. I don't necessarily play a role in that, but I do need access to the data or maybe I want to control access to the data.
Another interesting one is for trucking companies that are shipping hazardous materials across the country, and there might be restrictions for, you know, GPS, location restrictions. You know, I can't go through certain tunnels with certain kinds of materials. I may be, I may need to monitor the temperature of my cargo. You know, if it's above a certain temperature, then I can't go to other places. So there's a lot of interaction between these sensors and devices and management interfaces. It's not necessarily identity driven from a user perspective, not even, you know, except to notify the driver. You have to take this route or you can't go through this tunnel or over this bridge.
But Jerry, Jerry points out, there's a, there's a distinction we don't often make. And we talk about identity and IOT, which is you have the data stream emitting from the thing. Okay. So that's one set of data with a set of identity and access controls usually expressed at the back end, right? I'm monitoring it. And then it triggers some con some, some things happen, but then there's actually the device itself doing API interactions on my behalf. Those are actually two really different things. And the problem of, of combining those two is we find that the data stream coming off isn't necessarily something, the device is acting on my behalf. It's simply just saying I'm a device and here's a bunch of stuff. And there we have authenticity is this the authentic device issuing the authentic data, but then you have the device actually calling APIs that update things for me as me. And that's a very different conversation where you do have identity management of the human or the organization or the relationship manager coming into play. Those two have to be actually treated separately.
Yeah. But, but, you know, I think that the underlying point is at the end, if even if you look at a manufacturing environment where masses of devices, sensors, cetera are interacting in some way or another, where this human part, the relationship to humans doesn't play a role at all more or less, the problem still is who or rich thing is allowed to do what. So we are always back to the fundamental question of an identity and the access part, be it executing or using an API, be it some other thing accessing data sensor has collected. So at the end, it all sort of nails down to identity and access decisions at a far bigger scale with complex relationships between things or things or things, but also between things and devices and humans, cetera,
There, there are a number just for a minute, please, please. Then we can just, can we, can we just see the questions because there's a number of interesting questions related to the discussion so that you see what the people actually are asking for. But the first is, is this a separate discipline of device in things management, which has little to do with, I, I am, as we know it, this is one, one way of, of questioning this, this connectivity or this connection. The next is the next is more concrete. Actually it says, what is the identity? Is it a person or is it a tag or is it a profile again? I think we discussed this every year, but we need to adapt this definition also to our needs, to what we actually want to achieve. And
So,
So, and if views on this, I think Dan was,
It actually sort of, of continues on from the discussion. I'm glad you raised authorization because a big issue in the internet of everything is authorization. I was talking about an energy company previously. It was actually one that yo Martin introduced me to a while back. And what they were concerned about was that they had a lot of intelligent things in their environment that needed to be managed. They also had a lot of cloud services and vendors that were in some cases servicing or operating those things. And what they wanted was an authorization service in the cloud that would just make the right thing always happen. And I told them, well, you need an architecture before you can even start to conceive of such a service, but it was a significant moment in understanding, you know, what customers are really after they're, they're trying to manage very different physical environments. And to the question of whether this is still, I am, it is, but it's not, I am, as we know it, it's an I that has grown much more complex. Yeah.
So, so the question we could turn it around is the IM we know the IM we should have or should know. So if I go back some 10 years or so, I remember having conversations with organizations about IM architectures that, you know, you have to take into account, not only your employees, but your business partners, your customers, and even if you don't implement it yet, the design, the architecture, the view you have needs to be bigger. So a lot of identity management we have, I think, is not that the identity management we should look at. And so I would simply say, yes, this is still identity management because it's, as I said before, the same challenge, identity access, and it's finally ending up where it should be
There. You know, there's a lot of companies I'm thinking of heavy manufacturing companies. Boeing is one that has done identity management of equipment parts for a long, long time. And they just see it as identity and maybe not so much access management, but identity management of the individual parts. I mean, parts that go into an airplane. They last for a really long time for decades and they have to track them. They have identities that are unique and they've just seen it as identity management for a really long time. So I think it's, there's an existence proof, at least at least one that you can see them as the same. But I think there's some obvious differences as well. Some ones that are easy to think of scale, the actual attributes that you would track, particularly for smart things, but also for dumb things in of the equipment parts, the authentication mechanisms, obvious user interface, user experience, the particular roots of trust that you would use, you know, and working on a bunch of things right now where you're having to connect the sensor to device, to service trust all the way out.
That's a really big key privacy implications are different. Once you connect them to a human, you do have to worry about privacy and implications, but if it's just a device it's different and the particular relationship bindings. So if you have a device actually impersonating a user, that's as bad as when you have a, an application impersonate, a user, which is why, you know, oof codified the current practice that we saw to not have the password anti pattern. So we have an oof device flow now that has a good way of binding devices to people to avoid that. So those are some ways I can think of that are obviously different.
So there's a related question, which didn't make it to the top five, but nevertheless, I would like to read it. Isn't I OT more related to configuration management than to IAM. So let's continue, let's forget our, I, I, I am head for a moment and take a CIO picture. Where would I put the responsibility for, for gluing these together? If obviously I need to inter integrate these processes, who would I give the responsibility? Is it configuration management or is it the, I am people.
Well, you know, I think there's a temptation to overplay our hand as identity professionals in the sense that if we leave aside for a moment, the compute power of a thing, we just simply say, it's a device calling APIs and emitting data. In some regards, it's no different than desktop management, right? That's not like lose our minds and forget like computers or just things that act on my behalf and do a bunch of other stuff for me, a thing is no different in that regard. And so that there is, there is a discipline of people managing the inventory, the life cycle of that inventory, the identifiers for that inventory, the asset management aspects of that, which I think increasingly include security configuration of those kinds of things. And then there is the people that manage the things that transit through those devices, the identities of the individuals, what they can do the relationships to other things, and that's our world. But the other stuff I think is not a, a world we necessarily want to encroach on let's face it, most organizations kind of socket, mobile management, you're really gonna suck at IOT. Why would you step up to that page? What you want to focus on is the relationships of people to the things and API services more and more, and stick to that and get that right. And let operational management take care of the devices.
Well, maybe that's the sweet spot for us it or our identity professionals, but there's an underlying theme to some of these questions here. And, and to your question, Sasha, it's, you know, who manages the access between these devices and these services or, or these humans? Well, much of that is known only by the business people, because they're the ones that know what kind of services they're offering, what kind of customers they're trying to reach and so on. So we in it have limited knowledge or visibility to that aspect of the, of the question mean policy. Exactly. Yeah. But the business policy, right? Privacy policy, not necessarily the it configuration device management, which should never be their
Problem.
You need to, unask the question we don't, there's something we need to understand first before answering the question. I mean, if you're a smart garage door manufacturing company, well then, well, you're not doing IAM. It's your product that you make money off of, right. Or if you've just bought a bunch of smart door locks for your business facility, well then configuration management and credential management for the installer to come provision, the CR the, you know, certificates into the door locks is part of the configuration management of the IAM for the Dar locks you've just bought.
So, so, so maybe, maybe the point is, does the distinction between configuration management and IM that we really make sense of the future, or when does it make sense for which organization when not? So I think probably, I think we can, can't answer the question from a perspective saying we have that organizational structure, so we need to put it in some of the silos. The first question we should raise is, do we need as part of this overall digital transformation to use the, the bigger B password here, do we need to get rid of silos or to change the silos, at least before we look at, in which silo to put which responsibility?
That's an interesting question, because I, I really liked Ian's answer. It was pretty much what I was going to say that there was asset management and there was identity management in both of them deal with smart devices and machines that are in the enterprise. So you could look at it as through the lens of your existing it services and capabilities, architecture. You have an identity group that manages the devices when it comes to naming and authorization and authentication, and you have an access asset management group that manages vulnerabilities and configuration and inventory, but then there may be still other scenarios Fort that don't fit well in your existing organization structure.
So let me give a very short example of what I mean, why I think this is going to be an important question in the future, or maybe we need to ask a question differently. I don't, I don't mandate that the way the question I was asking this the right way, I just spoke with a manufacturing company that produces pumps, and they're, they've been now challenged by their, by their competitors actually, to equip electronic elements to that pump. So they can do preemptive manufacturing and lots of added value stuff that directly coming from them. But since it's so hard, actually to allow this devices to, to communicate through the network of the customer, they install GSM modules to, to directly communicate from the machine to the manufacturer's home. So who is the control of that identity? That's the question behind
Very much like a smart meter use case I've yeah,
It's very similar
About go back and look at the contract, right? I mean, like, this is not in the absence of a business relationship. So in some regards, you, the answer goes back to how did procurement arrange the relationship with the supplier? And sometimes you get really weird scenarios, like ones where we've seen you don't actually own the vehicle or the piece of farm equipment. You actually are just a licensee of the, the use of it. And when they expire their certificate, your tractor doesn't go anymore. And that comes back to what did the contract look like? And then it becomes an identity or access or security management problem. It
Pumps as a service.
Yeah, I think it also leads to an interesting point, that entire discussion that if you look at bigger things or collections of things, then it becomes apparent that, that we need to understand that there's not a single view on that. So my favorite example is to connected vehicle in the connected vehicle, you have increasingly the event data recorder, and you have a lot of parties which are interested in having access to the data. So the manufacturers, because they kinda learn a lot about how the cars are used insurance companies, police in the case of an accident, cetera, etcetera. So I think what this shows is that we can't solve these challenges with a concept of there's one thing, which is owned by one other entity. Who's the only one who has access. We need to have sort of privacy by design security, by designers, as a concept in that, in the sense of we, we are capable of flexibly by policies controlling and under which circumstances does someone have or something have access to that data. So we need to become far more flexible and, and far better in that area to solve challenges such as the pump, which is still relatively easy compared to the connected. Yeah,
This is, I, I like it example because it makes things very simple. You can immediately understand the complexity of the problem in a, in a, in a later larger scale.
This is something where, you know, a previous conference that I was at can't remember which one, cuz Q2 is full of them. But people were talking about microservices, having some problems around kind of the legal level of how to sort this out. And this is what you're talking about. And there's three things that I don't think microservices have sorted out identity privacy and security, three small, small little things. The, he just bolt that on later, figure it out it's but you know what I think might solve it. Blockchain. Yeah. There you go. Thank you seriously. I mean, we've got, I mean, microservices are designed to be so permeable and you know, what they haven't solved for is, well, in the Canera workshop this morning, we were talking about the BLT sandwich, business, legal, technical, I mean, you know, technical, you can figure out, but we kind of need the legal layer for microservices and identities are almost as much about a legal layer because they're ourselves and we need to figure that out cleanly. But
Here's the thing I, I think it's, that's, that's entirely true, but I think some of this is a symptom of, we continue to design things, thinking they are single use single user.
Yes.
Right. And when we start talking about like smart cities, now you've got layers upon layers of relationships to a thing that I might, I might legally own that someone else may be in their physical possession, emitting data to an untold number of places or sharing other untold thing. Except we still design our systems for the most part, thinking to be silo. I built this microservice just for me and it's super pretty and I'm only, only one can ever use it, which is total BS. Cuz once it's out there, everyone wants to
Use it. Well. And that's the thing, you know, a smart thing has APIs almost by definition. Although, you know, most so many of the consumer ones really don't and they ought to, but once you start thinking microservices, which you should be, and even the consumer smart things should be, you really ought to be thinking multi-user life cycle. You know, there was a session at the internet identity workshop a couple of weeks ago. I've just bought your smart home. Now what, you know, the life cycle of a home where somebody else new moves into it, everything has to transfer. And I think there's some good answers that can be had for that. It's not untractable at all. All we have to start thinking about that and it's precisely an identity and a privacy and a security problem.
Okay.
Yeah. Another question I like to pick here that I like again, more practical. One, one should be the, what should be the token to identify a sensor or machine. Can you maybe scroll down a little bit so that everybody can read it? It's on the bottom. I, I think we touched a number of the questions from the top. So therefore I like get new ones. Some requires yeah. Some requires way too. Rich request response protocol and trust centers do not yet have a business model for millions of machines are a Bosch or a Whirlpool or a buyer going to put down a hundred bucks to get a certificate for one device.
There's a lot there to unpack. Yeah. What's
The question there.
Yeah. Like a soap stack on a device that's gonna, work's
Be all singing all dancing
Question. Yeah. I guess I'm, I'm not quite understanding the, the question because it seems that the device is just another subject that belongs to a domain that has a trust relationship with another domain and the device can use SAML tokens in the usual way. Just like a person
It's it says it's too. It's actually I see now probably in many cases you cannot go to problems.
I can't.
Oh, good. That was sorr.
Okay. Yeah. So this is, oh, but we have, we have only 10 minutes this left. So maybe I leave that question for no,
No, no, no. So, so let's break it apart. Let's leave the certificate question for a second because it has to do with your deployment model and whether you want their certificate to be publicly validatable, let's leave that aside. Token format.
Well internet of things, I six everything.
Maybe not always, I mean, industrial deployments of that. It's not necessarily a publicly validatable certificate and for good reason, but let's leave that aside for a second token format. What can developers work with? What can things support? You can't have token bloat, right? You can't put down a massive Kerris ticket onto some device that's just not gonna happen. And what are developers working with? Well, to me, it's a JWT that you could sign. It's pretty simple. Don't overthink it.
Maybe it's not the above. Maybe there's some new, better format. That's more appropriate for this kind of massive scale.
If you can drive, if you can drive adoption and developer adoption with it. Awesome rock on in the meantime, in
The meantime, maybe
Could job, every manufacturer does what he wants. So yeah. Only have to do with the five usual ones from the business it world. Right?
I think if the device could handle SSL, TLS, it could handle SAML.
You wanna put a soap stack on a device? I mean, the nest is a beautiful thing. You're gonna dump like Ws trust on this thing.
I love SAML. Don't get me wrong.
I love, I love JWT too. So
I think that's, we built SAML with the tools we had lying around the house at the time and there's some friction associated with those tools that we no longer have that we've managed to start eliminating and we, we can eliminate friction and that's good. I mean, there's still some sensors and devices that have constraints and those constraints can go away over time, but still you don't have to, you know, build, build bloat in where you can avoid it, but there's technologies at the sensor level. And also at the device level that are, you know, that are working hard to, to build more trust in, you know, trusted execution environments. There's the epi technology from Intel that has some, some privacy enhancing qualities at the manufacturer level that, you know, there's lots of ways they're trying to sort of build in that sensor to device, to ultimately service qualities that we're gonna need recent te breaches not withstanding.
The other thing is I think we, we, I think Ian answer has gone in that direction that every thing will communicate through full stack of services. So we will see, particularly when we look at sensors, we will see a lot of situations where sensors are only accessible through gateway. And then it's from that gateway, you have to have a more complex security. And if you talk with the, the vendors in that space, they're looking at sort of layered approaches with more and less dump devices, so to speak. And clearly a light bulb might have less technology in than a car will have cetera. So, and, and then we will, will find answers. And clearly it's also, you know, at the end economy of scale works in various ways. And clearly it's, if you are starting to order 100 million certificates, you probably will have a different deal with your PPI than you have today for a few thousand employee certificates.
Yeah. So, but ultimately, I mean, I would agree that every device is or should be under control of a person. At least that's my ethical belief. That should be the case. Maybe there are different business cases, but so, but that means ultimately that these devices should be connected some way or the other to people. Right. And getting back to that, to that old question, maybe this, this discussion gives that, that discussion a new flavor. Then if you go back to this custom IM discussion we have year by year, whether it should be separate or together, does the O T change of landscape impact impact this discussion. So is it, is it changing the answers whether should customer IM should be separate or,
Well, I think it adds a different element to it. So if you think of an auto manufacturer, there's the, you know, the, their customers, right? The, the car owners or the car leasers that are, you, you have some aspect of managing those identities, but then of course the, the cars themselves are emitting so much more data now, and that is available either to the dealer, the manufacturer or the car owner. So I, I think you're over time in certain industries or certain scenarios, it blends more and more, you know, the OT management, consumer management and your internal identity management.
I think that's the point. And I've wrote blog post a while ago, which has been heavily misunderstood because I said, CIA, consumer identity management is not a separate discipline. There are new things in, but at the end with all the relationship, we have to have an integrated. So it has to, to fit together. It has to work together. The new things you're doing have to, to work with sort of a more traditional stuff, etc. I think this is a very essential element of that. So we can't just segregate it. And I, I always raise a simple question name, the one application you have in your organization, which is only accessed by customers, but not by employees,
Your comment during the keynote, also that it was increasingly becoming part of the business rather than a silo is very germane to this point of customer identity management. Because the customer identity management use cases, excuse me, relate very much to the business model of the company and how they're selling their products and who they're selling their products to. So it really needs to follow the use case of the business rather than some generic architecture pattern for how authentication should work in a authentication infrastructure. So it's really, and, and it's gonna vary a lot depending on the type of company for some companies, their customers may be fairly similar to their employee use cases, but for others, they could be very different. So you'll use different solutions, but you wanna have some common services you can use across both and some common governance strategies.
Well, I mean, connected devices are just another channel across which you're gonna connect to your customers. So think about how frustrating it is when you have one user experience as an individual calling a company on the phone versus getting a wholly different. I don't know who you are experience in person, like say an airline ticket counter. This is the same thing, right? So you're connected devices should have the give you the same, the customer, the same experience.
The way I think of it is the, the, the way you make choices when it is your customer versus an employee is in fact, you're not the boss of them and you can't, there's a
Different contractual relationship.
Yeah. You can't make them do things. And so, whereas, you know, in the era of, when we talked about B Y O D for employees, you can make them stop using Android devices. If you think they're unsafe, you can't make your customers stop using the cool new Android device. And the same is true of like, you know, let's say you're in a SCADA environment and you're worried about your employee bringing in an unsafe, new, smart microwave oven into their place of employment, which is a real concern, frankly, a consumer, you know, smart device, but you can't make consumers buy the cool new, smart microwave that turns out to blow up, or maybe the smart hover board, which do blow up. And the other consequence is when it comes to privacy, consumers have different incentives and you, you know, you do have different contractual obligations, as you're saying for those two populations.
Thank you so much. Can you please scroll up the questions to the top again? Just scroll to the top. Can you make that? Yeah. Perfect. There's one question. I think the third or four for, for closing this. Excellent. I think very, very good. Very excellent panel. No, it's just up there. Go up again. Up, up, up, up, up. No, that's way
Up.
Yeah. That up.
Where is this speaking of identities? That's your final statement you can make. Can anyone identify Sathi Nakamoto for all of us and let us know who is behind Bitcoin and blockchain. And so we may trust them any ideas closing this keynote, very short statement,
Tooth fair, no ideas.
It is.
I saw a article. I think it was dated May 3rd that somebody had come out and claimed that he was,
Yeah, the Australian guy.
Yeah. The Australian guy and half, half of half of the community believe him and half of them don't but given, so now we're even more confused
Given the various concepts of blockchains, do we have to care about,
Oh yeah,
We do. If you look at open SSL, but anyway. Okay. Thank you very much. Again. Thanks so
Much. Thank you. Thank you, Saha. We can go this way.
