Panel | Digital Identities and IoT - How to Leverage OIDC and OAuth 2.0 for the Best User Experience and Security! IAM Related Experiences From the Automob

My responsibility as a C of IC consult is to take care of our portfolio of services. So what are the identity access management vendors in the market we are working with?

What, on the new trends, the new technologies, making sure that our delivery methods are up to date and yeah. Therefore happy we to be here today. Super well, thank you. We appreciate it. Okay. I think first up, let's just agree on the definition of a device. When we see in say IOT device, what are we talking about? How are we talking a sensor, an actuator? Are we talking about a micro controller? Are we talking about a, a communication interface? How much are we talking about when we use the term IOT device?

Phillip, would you give us your opinion please? So, you know, it's, it's obviously going from very small devices to big devices in our company. We are working on devices that are in ranch price in between 200 to two few thousand euros, typically with two gigs to eight gig of Ram. So pretty big devices.

Generally, I would say sensor are very rarely connected directly on internet. If there are, there are extremely limited capability. So there's the biggest risk of usually come when you have a lot of complexity, which means that if you have enough power to support that complexity on your devices. So in our case, it's typically going to be a car, a train about and not to censor inside the car. Yeah. Very good. Okay.

Andre, your opinion. Yeah, I will completely agree on, on, on that. So the question from my perspective is when it's a point when a device becomes interesting and that's from my perspective, as soon as it is somehow interacting in an exciting way was a whole digital ecosystem out there. Yeah. So talking to other identities, other things, or acting on behalf of a human being yeah. To provide some examples for that, in addition to what Phillip already mentioned, household appliances. Yeah.

For example, the dishwasher who, which is ordering the, the washing power power on behalf, on behalf of the, of the end user. So acting for specific set of functionality, the ordering progress on, on other identity's behalf.

So this, this as exciting use cases. And also of course, when, when there are use cases, which allows these devices to, to interact, for example, with digital assistance. Yeah. Then there's enough complexity. That's an interesting device. Sensors are important.

Anyhow, not in points of digital identity for us so far. Ah, okay.

You, you mentioned that digital identity word, and that is the core of what we need to get to in this panel discussion. Some people would say a thing doesn't have an identity. It needs to be identified, but it doesn't have an identity to have an identity. You need to be a human being with attributes that contribute to your, your identity. Now I notice Phillip that you are working a great deal with O I D C and O Orth and are recommending that we use this functionality in the digital sphere.

Why would, why is that a good idea? Why do we want to take O IDC, which is typically used by us humans? Why would we need to, to issue an O or token to, to validate that identity? What's your opinion?

Do we, do we need to go that far? It's not that we want, or we don't want is we have to do, if we are willing to implement the new cybersecurity rules that we need to have in the critical infrastructure.

In fact, if we look in, in a car or TV or, or a ship, you have multiple identities. Obviously the ones that people in E C knows the best is the one used to attach to the people using the system. So in a car, typically it might be the driver. It buy means the mechanical. It might be the person renting the car. It might be the owner of the car. So we already have multiple physical and, and traditional identity, but we also have identity for every application. So each application has an application ID. And from this application ID we can give or remove certain, right.

I, I just take a simple example. Your geolocation system need to access your GPS. Okay.

If, if the geolocation cannot access the GPS, you cannot say where the car is, but on the other end, maybe the person using the geolocation system is only allowed to seize the position of the car with 300 meter of precision. Okay. So you have to compliment both identity to say, yes, I give a permission, but I limit this permission to a certain range because of the people using the service and to, to compliment on why using open ID connect, because it's working very well. Okay. So there's no value in reinventing the wheel.

And obviously when you look for the documentation, it's not exactly what they thought about the protocol and how people would use it, but it's, it's working very well. And in fact, we, we have published open source code on how to use open ID connect in with devices. So we know it works. Yeah. Yeah. So do we have to use it?

We can, can, can have a look to the use cases which have been implemented in a traditional way when it's about IOT for products, which are already out there and by not utilizing these, these new protocols. And typically it's fine doing it in any way, if it's just very, very single limited, limited use case.

But what, what is happening then is as soon as the use case grows, there are other actors, there are like the digital assistance in, in the, in the game or an eCommerce system, which is not required for IOT by nature. Yeah. But based on the use case, I mentioned, they ordering on behalf of a user, then we have these more complex scenarios. And then we have to use standards for that, not just for authentication authorization, but for authentication authorization as a very security, critical aspect. And therefore is a good idea using a standard on that.

And as Phillip mentioned, automat connect and has proven the value in the, in the real life. And that's the reason for the, for the great success, much easier to implement than, than the approaches before and secure, efficient way. And that's something what we of course also want to apply it to the IOT world. But of course not exactly in the same way as we did that in a, in a, in a web and, and app out before. Okay.

So what you're basically saying is we're going to take a similar technologically technological approach that we have with users and extend that to the devices that users are going to be using. And that's going to make it easier, more secure for us.

Is that, is, am I getting the, the right message? Yes. To make a concrete example. Yeah. We have in the eCommerce system, the API, which is used to, to order yeah. To order the washing powder. Yeah. This API is called by mobile app, for example. Yeah. And then we are using OS and nobody's questioning that. Yeah. There's a standard approach. So what's now the case if, if the washing machine yeah. Is using that kind of API, of course we don't want have a separate API for the same functionality. We want to have the same, the same kind of tokens, these kind of things.

But anyhow, what's inside the tokens. This has to change a little bit. Yeah. It's not just the user identity. It's also the device identity. We have brings these things together in order to have to have yeah. Authorization on that level in order to make sure the overall use cases running a smooth way for the end user. Okay. Thank you.

How about now the migration to the cloud and looking at what the cloud obviously, cloud can do much for us and particularly with the plethora of IOT platforms that are now becoming available, does the use of open ID connect and or tokens assist in that space as well? Again, typically it will be done through APIs, but would, is, is it superior now to use O IDC and, and or for cloud migration capabilities when we're using a platform in the cloud?

So, you know, I, I think one of the big lesson learned of the next generation of IOT devices is that the, the border in between what is in the cloud, what is on the edge and what is in the far edge is somehow decreasing because we have more and more power in, in a car. Typically you may have a gig of ramps and you have eight course. And so you have a lot of power in fact, and some people like, you know, the Gartner predicts that we will have more power on the edge in, in the next coming years that we have today in the cloud.

So, so there are clearly a lot of things moving, you know, from one way to another one, one thing that is clear is open ID connect, allow you to cross border those domain. And it's very important. Okay. You have to make sure that you can transfer the identity from the cloud to the car and from the car to, to the, the realtime device.

And, and you have to use it for user. You have to use it for payment. You have to use it for software update.

You, you have that everywhere. Okay. And open ID connect is a very nice protocol for doing that until a very recently, we had very strict border and almost each segment was using a profit tree technology. And when moving from one technology to another one, you had to reinvent protocol with the next generation of cars. This is not going to be possible already today in a modern car, we have 60 to 70 million slides of code. Okay. Which is far more than what you have for all Facebook.

And in the next generation of fully autonomous car, we predict 300 to, to, to 500 million slides of code, which means that this level of complexity in fact, required to have extremely strong standard to, to, to separate things, to control things and to implement or secure model and open ID connect is clearly a very good, you know, technology to, to do so. Yeah. Okay.

And, and you, Andre, would you concur, are you using any IOT platforms within IC consult? Well, not IOT platforms as a traditional way that I have the platform, which is having the digital twin of the device.

So that's, that's not, not, not exactly there where we are working in, but for us, it is, is getting important as soon as a digital twin is yeah. Is a, is a entity, which is getting, for example, the talking there, because it's a point for, for, for making, for making, for making the calls calls out there to the rich digital ecosystem. Yeah. Okay. Thank you. In terms of the abstract for this panel, we mentioned automobile, and we mentioned home services. Both of you have described devices in those spaces. Where does the need for identity data come in.

If we've got identity data that is being used to track our users, the user of the vehicle, the, the, the, the technician that might work on the vehicle or in the, in the terms of the dishwasher, you've got a user who's using that device. They have identities. Does the device itself share an identity too? Is it all part of a single identity and access management system?

How, how are you going to actually manage that in the future As today, we have already multiple identity, typically in a car. The first identity you have is your key. Okay. If you have a key, you can, you can start a car. Then you can compliment this key with a social identity, for example, to listen music because you have a diesel or Spotify account. So you can connect both identity in such a way that now you have a global identity that allows you to listen music in your car. You have some preference and can migrate from one car to another one.

For example, the language you like to, to, to interact with your preference. And this identity now is not attached to one car, but is moving from one car to another one. So at least in the model we implemented, we have a Federation of identity where you can, you can merge multiple identity in, into one global identity at the IOT level, and this create your context. Okay. And from that context, we, we can decide, what is the scheme you want to use? What is the language you want to talk, what you're allowed to do, what you're not allowed to do.

And, and we push all those privilege into the kernel and the hardware level in order to make sure that whatever happened, you're not going to bypass your privilege. Okay.

So that's, that's a way we do it. So we already have multiple identity in the system. So that mix between, you know, human identity, software, identity, object, identity. And honestly, I think the more we are going to move forward, the more identity we'll have to federate in, in IOT devices.

Yeah, Yeah. Maybe to a little bit to that. So from my perspective, of course, the device itself has to, you know, able to authenticate maybe based on a certificate, which is, which is provided to the device in an early state, but it becomes interesting as soon it is not just a device anymore, but it is becoming my device. Yeah. And then we have to do somehow building up the relationship between the user yeah. And set device. And is of course not always a one to one relationship. Yeah. But maybe the, or members of the household should get access to one of the smart devices.

Also the kind of, of small organization in that, in that story. And a very important point is, and this is something which really affects the, the, the user experience much is how do I building upset relationship? Yeah. And I think most of us have seen couple of good and not so good approaches out there.

And that's, again, something, something why I believe that Mai connect and, or with a specific new flows are generating a lot of value as, so for example, the, or device token grant or the myd connect client initiated back authentication, these are approaches in which we can provide tokens to, to a device, which has just limited capabilities for things like, like a authentication giving user content, these kind of things. Yeah.

Nobody wants to, wants to type in his password and the dishwasher and reads a lot of, of legal agreements, giving consent and these kind of things in order to allow that operation of ordering something. Yeah. Doesn't make any sense that has to happen on a different digital touchpoint that typically on the mobile phone. And that's something where these kind kind of, of flows really helps us because we do not have to spend hours of hundreds of hours in, in specifying somehow proprietary protocol for making that happen, but we can take what what's the community already provided to us.

And what's already proven in a lot of, in a lot of scenarios, real life scenarios out there. Very good. Thank you.

Look, we've got a couple of minutes left. I just wondered if there's anybody in the audience that would have a question. I'm obviously a disadvantage, cuz I can't see that, but are there anybody sticking up their hand would like to ask a question before we, before we end? So at the moment I don't see any hands shooting up, but I have a few from our virtual audience. Oh thank you. Yeah. So the first question is with autonomous cars requiring 300 to 500 million lines of code, how do we prevent zero day attacks against that much code? Yeah.

You know, this week, the same week there were Conran in Munich on the subject. And in fact, I'm switching in between both contract. I gave a keynote sessions this morning in that conference about cybersecurity. Obviously it's, it's a huge risk. Okay. And the only way to address that is by building stuff in a more standard way. I think today not only is the automotive sector, but the embedded sector at large is designing custom systems. They have custom hardware, they have custom software, they have custom protocols, they have custom everything.

And this is not going to fly with this level of complexity. So we have to make sure that we rely on more and more standard things. And clearly from a cybersecurity standpoint of view, it's only going to fly if we can rely on normalized middleware and clearly open ID connect is, is one of, of the good candidate, at least for the authentication. But also what was presented on Monday here with the secure API model is, is really very, very cool and very promising. Yeah. Maybe I'm gonna Phillip of course, yeah. Please.

The expert for, for that question to the, the patterns which have seen that they generate a lot of, of value in, in limiting the tax surface. Like the zero trust architecture is of course something which applies to these kind of scenarios as well. Yeah.

Not, not happening on Harding, the specific system, but, but limiting, limiting what, whatever can be done with kind of credentials, tos, whatever is going to be exposed to the attacker. Yeah. Thank you for both of your insight here. And from my end, I would love to say thank you. First of all, to Graham who moderated this, he needs to jump and be prepared to present to you next. So we can say a quick goodbye to him and a thank you. Thank you very much.

And to our two panelists here, actually I have one more question from the audience, which I'd love to ask, which is that will vendors agree when mitigating, when migrating, excuse me, will vendors agree when migrating one digital ID and her data to another device or will there be a technical or marketing borders, which hinder that individual from doing so, Could you repeat that? I'm Not sure. Yes. Yes. So when an individual, when an individual migrates one digital ID and data to another device, what borders will hinder that or will vendors agree to facilitate that?

I, I, I think that's more a marketing challenge than a technical challenge. You know, obviously it's clear that Toyota BMW, they want to have their own experience and they want to retain their own customer. Which mean everyone is willing to keep the data. Everyone understands that the values in data and a car knows a lot of things about you. Okay. A car know where you go after work. If you stop in a bar, if you, you know, so we can deduct lot of thing, you know, whether you, a colleague, you smoke, you have a mistress.

You know, we know all of that. If, if you're nervous because we, we, we can see that on the, on how you drive your car. So obviously all those data could interest a lot of people. Okay. Luckily we in Europe and probably they're going to stay in your car. Okay.

But yeah, it's, it's a big risk now, will people, at some point share information, maybe I saw this morning that Reno and Volkswagen and demo, I think agree on having a share platform for secondhand cars, nothing prevents them tomorrow to say, we have a share platform to exchange information like, you know, your, your preference and your prefer language.

And also shares that with one company, you know, the car industry is moving in multiple direction, not only the connectivity, but also the power pro you know, electrification, you know, renting car, smaller car, you know, it's, it's, it's moving everywhere. Okay. And identity is not going to escape this movement. Okay. We also have to move. Yeah. Yeah. Do you have any final comments here? Yeah. Yeah.

My, my opinion on that one. So first of all, when it is about tokens and, and so on, it's, it's the easy answer. Yeah. The token has to be revoked. Yeah. In order to make sure that the device cannot act, the old device cannot act on behalf of the user anymore for anything that's the, that's the easy thing.

But the, the other thing is that the device is be able to collect a lot of data and maybe to be con configured in a specific way. Of course not the dishwash. Yes. But what's about wifi speaker, which is getting ideas of, of your, your playlist, your preferences, you connected to your apple music as Amazon music, Spotify, whatever. And these kind of use cases will become more and more complex. And we are spending more and more time making that device, my device in my digital ecosystem.

And, and, and, and here's the point. I think it's, it's important that we, that we, as a, as a consumer are really for things awareness vendors to give us access to this, this data. Why? Because that we are able to migrate away from it without destroying our digital legal system and spending a lot of, of, of time in building it up again. Yeah. Today it's not, not, not, not so important already, but, but it's becoming more and more complex. And therefore, I think for the future, it will be a very, very important aspect. Absolutely.

Which is why we're here discussing this and considering that what's coming for the future. So thank you so much for both of you for being here. And I thank you from the audience, perhaps. Great. Thank you.