Per Hägerö - Authentication in 2020

So today I'd like to introduce you peer here ago. Pier, are you here?

Oh, he's coming. It's too hard to see down the back there. PI is from is the CTO of nexus and authentication in 2020. Hopefully it's not passwords. You never know morning, everyone. Let's see. So I'm here to talk. I'm the CTO of nexus. As you can see there, you can figure out what the picture has to do with me in terms of my identity and give you price. If you can come up with that later to us, speech is about how can authentication be done in 2020, which is quite far away, but it's soon be here.

So, first of all, I'm not gonna talk about any death of things today. So I think this is the live and kicking day for I am. So you won't see all that in my presentation. So what are the driving? Some of the driving forces for authentication in 2020. But if we look at today, mostly authentic authentication is around identifying persons and yes, we do authentication on devices, but your infrastructures that you have today are focused on people and you have various different means. You have the passwords and you have other different kinds of tokens.

And we always talk about the factors of authentication. So how this one factor, it's two factors. It's three factors sort factors. But if you look at what will happen in 2020, is that the number things that you need to have in your infrastructure for authentication, it's not just people. It will actually be devices and these will outnumber the number of things that you need to handle. So the internet of things, or the internet of everything and et cetera, that will also be in your infrastructure, which means that you will need to look beyond just doing the factors.

Cause it's pretty hard for a car when it comes to garage to pull up a, a one on password token, generate a one on password and present that to the garage to let them in. So you need to think, think about this. As you go forward, you need to have internet to things, entities and authentication in your authentication infrastructure. You also do authentication mainly today that you are providing the authentication layer. So you control the end user user experience. You can do it like this.

There's of course, many other examples, what we know and we'll see today, I, this continue to explode is of course that you will not control the user experience, which means that this was also challenge your authentication infrastructures, because if the access is down via an API, instead of user experience that you control, your authentication is likely to break as well. Which means that you will need to have Federation technologies. That's the previous speaker talked about in your authentication infrastructure as well, because you will need to rely on authentication of external Porwal.

You need to consume the APIs in your authentication infrastructure as well. So things you think about now is when you go back to work is that you need to have an authentication infrastructure that has Federation capability. It needs to support some of these standards. There will new standards, right? Of course you need an ideal infrastructure that you can add additional services.

It was important that your Federation solution can act both as an identity provider and as a service provider, because you will need to access and authenticate and things that are not federated and enabled today, which means that you need to consume, or you need to bridge between different protocols and present them to another system. And of course, you need to link down your authentication infrastructure with this Federation gateway so that you can provide graphically, you know, the normal you access and the API access saying that that will move you to. So what are the finest level one?

But one of the key problems with authentication today is of course the, that we don't make it easy for the user there, of course, solutions like the fight Alliance that try to make it easier for users to use that there's a single interface I like to use to, but I've been thinking about how could you really make authentication easier? So if we look to the real world and make some comparisons there.

So if you think, if you think now about your and infrastructure as a baby, so when a baby's born or before it's born, it can potentially develop a relationship, a new full authentication with this mother Because They have a, you know, to spend nine months together before they get out. So they have something, they do some kind of biometric things. Maybe once it's born, what happens then? How does an baby authenticate and trust other people? That's the question.

So how, when you do this, of course, because you have self claimed identities, I came up to my children and tell them, I'm your dad after rep repeating that 10,000 times, they probably, you know, they got it and they trust it. Then you have the federated approach where I tell my son that this is your sister and vice versa, and there's other people. And just continue to repeat that. And then they start building up a level of trust. They start adding additional attributes, of course, that they can see, they can smell. They can recognize the voice.

So they have a broad, and once they get older, they can stop making some inte decisions. They're on room. See they can, they have building up, of course, the use to base that they have authenticated, but there also building some kind of intelligence into it.

So how, what does that have to do with it? The thing is that the intelligence part here is important. A child is, or the baby is starting to collect a lot of the data in order to do recognition based authentication. And then at the beginning, of course, they need to trust someone else. But in the, in the end they haven't collected enough data to stop making intelligent decisions about is this person really this person or not.

So if you can get your authentication infrastructure intelligent enough to start analyze the user information that you have collected, you can start building up a pretty good understanding of who the user is without having provided them different tokens. So based on you clean information that you collected by the users, you could actually let them in once they appear at the doorstep, either at, in, in the fiscal world or in the digital world. So this thing about basing authentication on data and instead, and analysis, what could point in that way?

If you look today, of course, it's, it's difficult of course, to get enough data about an end user before they have done a lot of regulation, you got to know them a lot, but if you look in six years, there will, of course be a lot of solutions that will aggregate enough data about the end user in order to make an authentication. That is that you can really, really trust Because I add a lot of devices for myself, of course. And if we look at 2020, there will be lots of devices that collects the use information about users that is, is important for you.

And if you get access to that, you can make a pretty good authentication based on that data without having a previous relationship with their user or the thing that is trying to access your data people today, even though we have a big discussion around privacy, we have a sharing generation. People are used to share data about themself. If they even more, if they can get something out of it, of course.

So if I can trade off, giving up some parts of my privacy without having to authenticate, when I use a service in a traditional way, I think in six years, that's actually something I would be willing to do. And the trend is also down that we have solutions today that can aggregate store and analyze vast amounts of data. And in six years, these solutions will be even better in order to create, for instance, an algorithm that will aggregate take in a lot of information, make an authentication decision and decide if the user should be let in or not. Of course be.

So that's the similarity between what the shield style builds up during the years to make an, a consistency of a person and what actually your authentication infrastructure could do. So what's needed them to, to do this.

You will, of course, need to have, would need to develop, use of consent, to allow Porwal, to use data about them. We need to have an effect in algorithm to gather and store the data.

Of course, we need to protect the data and have a respect from a legislation perspective. I had a one hour discussion with my CEO last night that were drinking wine that ended up, I don't think we agreed, but it's, I think it's very important that democratic governments constitute legislations that makes sure that an end user can trust that if I handle my data, nothing will happen to it.

We can, of course not do anything against data ship, but in the democratic world, we should least for sure that these governments or respect that we want the privacy of that information and only share it with Porwal that we have decided to share with today.

There's no algorithm to actually do an authentication based on data in a, if you look at the, of course, some, but if you want to vast a lot of data to make a decision on there's no effective algorithm that will be available and we will need also an acceptance from the market, from users, from customers, etcetera, that basing this authentication without the factors will be a sufficient way to authenticate user. So you don't need a free factor authentication solution solution to determine the identity user. You might need 500 attributes of data, but there's nothing that you need to hand out.

So two things used to do when you get back, you start exploring the, the idea authenticating user based on something else than your, just the factors and make sure that your authentication infrastructure is agile enough to adopt new technologies, new methods, authenticate users. You can roll these out during the years. Thank you. Did I? No passwords, No passwords, hopefully not.

So, so in this model, this is very similar to what we tend to call risk based authentication. So the analysis of multiple factors associated with the context. So how do you think about risk based authentication in this context?

I, I think that's, that's the starting point, but I think what this does is that this sort of takes away. So I think a lot of risk based authentication is still based on, on some kind of factor that the user provides. And then this case, the information will already be provided If, yeah, actually not so much, certainly in places like Google and Facebook, there's a continuous evaluation of all kinds of context associated with this. So I think they may actually be somewhere down that path.

The last question I wanted to ask given we have a couple minutes free is how is it that the user provides access to this information when they're actually in the process of authentication? So you've gathered it all. How would you actually imagine that you would get that information to establish that it's actually the individual user I'm talking about? What would that process look Like? I think there will be a, a number of data services that you, that you as a service provider will go to where user already left information.

So there would be like a, your big data pool allow the users you used to sort of gives its consent that, you know, you, yeah, I'm par here's my data pool that you can access. Right. But what we need to know is that you're actually the real holder of that. So given that it needs to be some kind of knowledge based authentication recognition, how would the user establish that they were actually the ones that, that information was about at authentication time? I think that that since the AUM isn't sort of done yet, I think will consist of that.

It will be so many parameters that you will have a certainty that you will determine anyway, without having a knowledge based authentication. Okay. I think this is worth a much longer conversation. Thank you, Indeed. All right.