I thank very much and, and welcome to the session about digital identities, IOT, and a lot of, of user experience and our learnings from the projects we did in the past. Yeah. We can share some of the challenges, some insights, but also give some, some, some advice how to make sure that we deliver successful projects. When it's about IOT and digital identities. Few words about IC. We are a system integrator, which is completely focused on digital identities and are in the market. Now for 25 years.
I only as the city of IC consult, taking care of our current landscape of partnerships delivery methods, but also about our vision of digital identities in the future. Okay. Then let's then that start. Do you see the woman on the cross trainer? How she's smiling? There's only one explanation for me. She did not try to log into Netflix on the cross trainer, right?
Yeah. So what we see, unfortunately, when it's about IOT and, and mainly from the, from the consumer perspective, we have really clumsy user journeys out there. Yeah.
We have to type in passwords where we should really not, not do it, that from security perspective, but also from a, from a usability perspective. Yeah.
We are, we are trained to use complex passwords to use passport managers, these kind of things. And unfortunately I cannot install one passport on the cross trainer of my gym. Yeah. That's one thing. Yeah. The other thing is often when it's about connecting devices. Yeah. The initial registration, bring it into my digital landscape. That's also something, what is very, very, has a very bad user experience.
Therefore, let's talk a little bit about how it can, can look, look like and why it is important to make sure that this is working based on standard protocols. Yeah. That just maybe good point to start to start that discussion. Yeah.
Management of digital identities is so far clear to most of, of the audience. I'm quite sure what we have to have in mind is that we are not just talking about the humans, but also about the smart devices and making that relationship, establish that relationship between the device, the smart device and the human.
Of course, this is not always one to one. Yeah. But many to many. Yeah.
Depending, depending on the, on the use cases. And as soon as you have set life cycle in place are able to, to build up these relationships. Yeah. Then the hard part of the journey begins because we have to integrate them. Right. Making sure that our systems of applications is able to talk to these identities, vice versa. We have to make sure that we solve the authentication authorization challenges and so on, and what is not the big challenge at the beginning, but very likely to come up soon in, in, in project.
Soon after you have that solution in place is bringing it together with a large dig digital ecosystem, which is already out there, of course, for the digital identities, as you likely expect, if you're in a customer scenario to provide so party locking providers, but even more important is to leveraging all the digital services which are already out there. Yeah. So for example, making sure that the smart devices we provide are very well integrated with digital assistance like Alexa here, or that's the next step.
There are couple of companies which provide access to their product, physical products or digital services via developer Porwal here adjust a few examples or a very huge marketplace providing, providing AP is, and they are often very exciting combinations out there. You are likely not aware of yeah. An example, which what I really like, like, like to present is my smart lock for the front door of the house.
Yeah. Can be controlled by our, by our app. That's nice. Yeah. The alarm system can also be controlled by our app and has APIs. Yeah. The vendors do not know each other. Yeah.
But it makes absolutely sense. Sense if I unlock the yeah. Then the alarm system should be disabled yeah. Or dis armed. So this kind of use cases and the good thing is in the past, we were talking about, about making these integrations completely pro proprietary, starting at, at zero and designing in designing everything. And at least for the digital identities and authentication authorization based on, on ID connect. And also there's a lot of work already done for us.
What we can now leverage by using the products which supports these standards and making sure that, that we follow these paradigms, making our IOT devices, our digital services. Yeah. First class citizens in the digital ecosystem.
And what is very important really come up to that point later. But what is very important, this is from my perspective and competitive advantage to be part of such a digital ecosystem because the system is completely not under your control. Huh.
But as soon as end users investing into it, integrating your product, your services in his digital ecosystem is getting harder and harder for him to move away from that. Yeah. Had recently the discussions with another participant of the conference and we all invested a lot in digital content. Yeah. At apple or Google. Yeah. Or Amazon and likely it's a large loss to move away from that provider. Okay. So I think that's familiar to, to, to some of you the, or device authorization grant, or you've seen it as somehow, don't want to go into the details of that.
We, we implemented that couple of years go the first, the first time it's a core idea is a following.
We have a device, the device should be able to do something. Call APIs huh. In a authentic, protected by authentication authorization. Of course. Huh. And in conjunction somehow with the user identity. Yeah. That's typically that that's typically the task and the good thing is that was protocol. There's also device authorization grant to be precise is providing us the foundation. The foundation for that, the end user journey is typically something like that.
He's act interacting with the device and the device recognize, okay, now I have to be able to act on behalf of that user for a specific purpose and have to go into the process, getting tokens. What we see very often is that a QR code is used to be scanned via smartphone and then authentication authorization in terms of giving consent to allow specific operations will come to that point later is all happening on a mobile phone, not on that clumsy device, the cross trainer, whatever, but on the phone. So it's convenient if the user's already locked in, it's already locked in in the app. Yeah.
There's no additional authentication. We have just a constant piece and that's it. The device is pulling, we're pulling for, for, for the tokens. And after it's done, it's able to act on behalf of the user, the exciting things here are now following,
First of all, we can leverage single and on if it's, if the user has a session, no authentication again, then we have authenticated user in the back end. And maybe also the authenticated device, if the device is able to authenticate, which is supported by the protocol. Yeah.
But of course we have support that as well in the process of, of enrolling the identity of the device. Maybe based on certificates maybe on, on, on private keys and using talks, different options for that. But anyhow, sometimes there's not the need for doing that. Sometimes it's enough to have a device, which is loud to act on behalf of the user. That's not too complicated. It's proven there's a couple of solutions out there, but unfortunately there are challenges. Yeah.
First of all, the enrollment of the device,
This requires, this requires depending on, on the nature of the device to be able to provide this kind of credential wrong process in a stage somewhere in production, maybe that's something, what you just do not have in place so far. So that can be, can be time consuming to, to bring that into the, into the overall process. And we learned, we have to be very early with that. Yeah.
In the it, we are agile, right. We get a new user story in the next sprint and we are, and we are taking care of that when it's about hardware and production. Yeah. It's a little bit different. Yeah. Then maybe we are not talking about two, two weeks before the next sprint, but maybe we are talking about 18 months or something like that. Yeah.
That's, that's really can be really a challenge. If you miss a specific timelines, you are out of the game, you have to, to wait until the next release cycle offset specific hardware, which is in couple of years.
Next challenge. I want to talk about, as I mentioned, or also really the glue, not just the glue code, not just for, for getting a talking to that device, but also for the whole ecosystem of mobile apps, talking with, talking with APIs in the back, leveraging the digital identities out there, calling parties at a third party, dealing with Amazon Alexei.
And you have to have these capabilities somehow also on your gateway or middleware components. Yeah. Which have been maybe in the past design to work with the device without any user context. And now you have to user context and now you to be able to, to, to deal with it with a protocol, the good thing is most gateways out there in the market can be easily enhanced to do the required validation of talks and refs.
What is somehow not somehow. Yeah. Let's say a surprise and a nice one. The limitations you might have here. Yeah. You often an identity provider product. Yeah.
Depending on the language you're talking about authorization server or the ID provider, I'm not sure why we have two different trends for that, but anyhow, there are different ways to, to design talks. You can have value talks, jots, which are signed or encrypted. You can have reference talks, both have pros and cons. Yeah. But maybe the product you are using is just supporting a subset of these possibilities. Yeah.
And, and Z ANSYS can really result in limitations. And typically at the beginning of a project, when you're talking about the MVP, you are not talking about the token designer. It just doesn't matter to you. Yeah. But if you're then later in a high scale scenario, if you, in a situation you to provide a couple of data within talking so that you can consume them easily in the gateway for authorization purposes, for example.
Yeah. Then you can hit the limits. Yeah. And then it's very, very difficult to make such a change.
Switching the token design in a system, which is under very, very high load. Yeah.
With, with, with hundreds of gateways out there and many thousands or even millions of devices. Yeah. So this is something you should really think about early stage, not too late. And the last point, and that's typically something which is completely not in the focus is the scope management scope and consent typically.
Oh, well we don't have to take care of our contents, but yeah. We are, the user is accepting some terms during registration and we are fine. Yeah. That's typically the starting point of the discussion. Yeah. And that might be okay. As long as you are completely in the context of your organization. Yeah. Your customers know other legal entities involved and you're taking care of very few concerns for marketing mail and so on.
And of course what you're doing is a user, but as soon as you want to participate in the digital ecosystem of your users yeah. You hit these limits. Yeah.
Because I really assume you want to ask the user before allowing Alexa to do something, which is fridge, dishwasher, car, whatever. Right. And then you might realize that the solution you have here in place is too limited. Yeah. Even if you have the checkbox in your IP asking yeah. Do you support management and yes, yes.
Will, will maybe realize that it's not good enough concrete example for that. There's a concept of dynamic scopes. Yeah. The roots are somewhere in the open banking area. That's but it has a lot of potential in IOT scenarios. Why? Yeah. Traditionally the concept would look, something like that. We have a specific API, for example, the vehicle API, let's take a simple use case, locating a car.
Yeah. We have the vehicle API and then you will likely use kind of concept. Maybe you have kind of management domain. You don't wanna mix up contents for, for us and Europe for good reasons. Yeah.
Then the API, then the functions, then the scope, something like that. And that's fine. You're using it on your mobile device. And maybe you, you don't want to ask for that content because your completely control the app and the user already agreed signing the contracts. No need for that. But anyhow, now, now we have Alexa in place. Yeah. And then we have the situation in which we definitely want to ask. Yeah. And maybe not just for any vehicle. Yeah. But maybe for a specific vehicle. Yeah. If I have more vehicles in the responsibility of my account. Yeah.
Then I don't want to have the possibility to locate the car in every single for every, every single single vehicle in this situation, dynamic scopes, as an answer, I have static part of it in the part of it might be, that's not relevant for your business today might be that changes in the future.
And if you then do not have the capabilities in place that can be very painful, but there are couple of other learnings when it's about scopes.
So the very first, most important she challenge from my perspective, convince the product online business that we need to have set concept of scopes and concepts in place. Even if we do not need to have it at the very first beginning, based on the fact that we are not open to interact with others. Right.
But, but I'm quite sure this will come pop up. And what I learned is that there is really no valid arguments that our, our users cannot deal with. It is too complicated. Something like that. Yeah. You can look to some of the players outside the market, like, like Spotify or don't have to explain the business of them and what they do very good is being open, interacting with many parties out there with smart speakers and so on and being able to, to leverage it in my, my, my, my car and whatever.
And a concept of scopes is something that is used at Spotify and what we clearly see doesn't affect the rating in any way. Right. So the users are happy that they can use Spotify everywhere. Right. Not just on their mobile phone and they can deal with scopes and well, the next question we should take care of is who is in charge of managing them. Yeah. Because it's something, what changes over time. Yeah. You're providing digital services and you have, so you have the knowledge, what could make sense to ask the user for yeah. But there are also arguments making it central in a consistent way.
Yeah. Having in mind that there's things like translation, which have to be in place very bad idea, enrolling your services into a new country and not having the language support for that country, for that specific scope, which has been introduced by a complete different department.
Right. So that's something what we have to have in mind also also somehow challenging is a authorization concept. Yeah. We often have the discussions.
Well, no, we are not using roles anymore. Yeah. We are going for, for alls that's authorization protocol. Yeah. And we have scopes, unfortunately it's a complete different dimension. Yeah.
Looking, looking on authorizations. One has a user, the, the, a view of the subject, the user, the other is more question, what does the user allows an application to do, or even what is an application, a device app, a digital service allow to do in general on a API, on a API level. And then what I really, what I'm quite sure is that, that the way we are asking for concept will become much more complex. If you're in the situation in which we allow a device to act somehow autonomously on our behalf.
And that's really not, not unlikely.
I having the dishwasher, ordering the supplements on my behalf. Why not? Yeah. I I'm quite sure. I want to give him some limits. Yeah. He's allowed to order the supplements. He's not allowed to order maybe the new dishwasher until he realized he's not able to do the job anymore. Right.
Or, or if, if the provider is increasing the prizes. Yeah. Maybe I don't want to allow him to, to automate that order anymore. Yeah. So these kind of scenarios will, will pop up. And that's something what we have to have in mind when thinking about these things. And then there's one last learning, having discussions based on just PowerPoint explaining how the user journey look like and so on. That's difficult. Yeah. Because you have completely different background in the different, different departments, different views on the products and so on.
And what we, what we really learned, what is accelerating these discussions is prototyping. Yeah.
Making, not an MVP, but just a very, very simple prototype explaining, showing the user journeys and what we, what we realized that's not set complicated by leveraging low code platforms like Notre or others by, by leveraging the very simple, limited I devices for showing up QR codes, by the way, Notre is very good in doing the all part, the API part, the web part on the one side and the MQTT part on the other side.
So that allows you easily integrations and making, making prototypes, which feel, give an idea how the user journey looks like later on, on really have to reduce disappointments when it is when, when the prototype based on the real hardware has been built. Okay. Yeah. That's it.
Any, any questions.
