Identity of Things: What is the identity?

Hello, everybody. So, I ask the question, when I say or ask you what is an identity, most people are going to have something that comes to mind. I don't know if it's anything like me, but when I think of identity, I generally think of a person. I don't think of anything else. NHI or a workload identity is not something I generally think of. As we went about trying to figure out how to support our business, that's exactly the question we had to ask ourselves. Before I get into the details, my name is James Naughton.

I've been working for DB Schenker for the last 15 years and been head of the Identity Access Management there for the last 10. I made my way into that by requirements engineering, kind of trying to do what Steve Jobs did for the iPhone, make identity usable for our business. I'm married, three children, wife, and because I don't really like the complexity of anything else other than humans, no cats, and no dogs. Enough about me, though.

Most people have probably not heard or don't really know the details of what DB Schenker is, which is okay, because DB Schenker won't exist or doesn't exist anymore. It's been taken over by a Danish concern called DSV, but the project we did here was still part of the DB Schenker context. That's why I'm going to present this originally from what we did with the Schenker colleagues, and at the end, we'll have a look at what this might mean for us. Schenker has been one of the largest logistics companies in the world for the last 10 years, in the 4, 5, 6, 7, depending on how you measure that.

Created or first set up by Gottfried Schenker in 1872, so about 154 years ago, and we have an annual turnover, I think, according to this number, of about 19 billion euros a year, so quite a large company. And because today the relevant topic is to do with land transport, I think the number we should look at is 100 million shipments a year. So we have, and now I go a little bit and look at what land transport is. In a logistics provider, land transport is anything we move with a truck, a van, or on land. It doesn't include rail.

Deutsche Bahn separated the rail from the Schenker concern some years ago. It's anything else to do with motorized vehicles, or even pushbikes that go on the road.

In Europe, because that's where our pilot for this project has started, we have about 400,000 shipments a year. There's lots of other numbers there. This is one of our standard marketing slides. I don't actually understand all of them. I'm not a logistics guy. I'm an IT guy. But I think the thing which is really interesting to see is we've got 30,000 of our own trucks here in Europe. And to be able to move 400,000 shipments a year on the road with 30,000 trucks, as well as having additional capacity that we buy in from subcontractors, we need a lot of people.

We really do need a lot of people to be able to make this happen. And when we think about the problem of onboarding employees, I don't know how many people here have the concern of how quickly can we go through the joiner, mover, lever process for fixed employees. This becomes even worse as soon as we start to think about partners or subcontractors. It becomes even less of a nice story to talk about when you start talking about blue-collar workers.

So people, frontline workers, that don't have access to any form of IT device. They don't have a phone. They might not have an email address. They might not have a mobile phone that's given to them by the company. Here in Germany, that's a big problem. And that's only if they're engaged in our ecosystem. With the number of employees or people that we need to move, the amount of stuff, I'm going to say, in Europe, we engage thousands of subcontractors. And I'm going to guess that probably millions of drivers work for us over the different years.

So to be able to make that happen, Schenker set out about 10 years ago to digitalize this whole platform. They set up a carrier platform. This carrier platform was all about getting people to register. Everyone's probably got some form of registration. We've got a registration form like this. You can register as a carrier. You've got an email address. You go through, you put all of your documentation necessary to be able to drive for us. Have you got a legal entity? Have you got all of the certifications required to be able to move everything around?

And then these carriers, they engage with us on what we call connect to drive, which is a platform. Think of it as eBay for shipments. If they've got a truck, maybe it's sitting in Hamburg, and it needs to head, I don't know, into Barcelona in three days, four days, five days time to pick up the next load, then they can bid on taking some shipment from Hamburg, maybe to Frankfurt, and then from Stuttgart through into Paris. And they go onto this platform, they bid, and if they win that engagement, they sit down and find a truck. And that truck usually has a driver.

And they send them to the location to pick that up, but that person has to engage with us in IT systems. And all of a sudden, it's very difficult for us to know who exactly is that person who's going to turn up. When we introduced this integration with the driver platform, which has also been digitalized in the last eight years, we went from having a local PIN and PIN, four-digit ID and a four-digit PIN to allow you to get access to point of delivery information, to having to go through a full-blown registration with first name and last name, with telephone number, with email address.

It had to go through all of the onboarding that we had for all of our white-collar contractors. And you probably can guess what happened. It was a huge, huge level of resistance. And so the drivers would turn up at the location and say, I'm not going to use your IT systems, just print it out for me and I'll do it. The result is that this new application, which was supposed to give us visibility and accurate GPS and tracking and be able to allow us to give this further on to our customers, wasn't being utilized.

So this huge project should have been very successful for this type of large-scale, very, very dynamic use case, didn't work with our model of how an identity should be accepted. And as you can imagine, there were some pretty unhappy people. So what we did is we sat down with the business, not turned away from it, we sat down with the business about six months ago, and we said, well, what do you actually want to do? What is actually the problem? Do you not need to know? It's John that's going to pick this shipment up and move it from A to B.

And the honest answer was, which completely surprised me, is no, they don't care who drives the truck. All they need to know is that the person who is sitting in the truck has been authorized by the subcontractor that won the bid on the shipment, has given them everything that they need to execute that piece of work. And the next thing they said is they don't want any form of registration. They want it to be seamless. So what did we do?

In the identity team, we went into our own little hole with the IT from the logistics colleagues, the land colleagues, and we sat down and we actually asked ourselves a pretty hard question. I said, well, what on earth is an identity? A couple of years ago, I stood up here and I said, an identity is anything or everything is an identity. Anything that can be authenticated or authorized is an identity. And that's exactly where we started. And we said, well, if all they need to know is who has been authorized to do something, then why don't we make the identity the shipment? We thought about it.

What's an identity? An identity is just an object with some attributes. That object goes through some processes like joiner, mover, lever. And the result is we can authorize access to do something. And that's exactly what we said.

Well, why can't we make the shipment our identity? We can give it an owner. We can give it a starts and an ends date. We can give it a unique identifier. And we can grant it some credentials. And then we can provide those credentials back to the subcontractor using two separate channels and allow them to get that to the driver, which can then log in without ever registering to execute the trip. The business liked it, and so we did it. In October last year, we started doing this. And lo and behold, we had created the shipment identity. We don't call it the shipment identity.

We call it the identity of thing because it's not an internet of things. It's not a smart device. It's not a light bulb. It's an identity. It's a full-blown identity. It's got its own onboarding process, joiner. It's got its own mover process. You can change stuff. You can ship it around. You can change the owner. You can manage credentials. And of course, it has an offboarding process. It has to be somehow terminated. But because it's got such a specific set of entitlements, the blast radius, if this is ever lost, is very low.

We can get around the idea of needing to know multi-factor, all of these typical topics we have and we've been talking about in most of the other sessions. So now, let me just run through that. So I said I'd give you some kind of an architecture. This is my architecture. I'm at most business architect. So we have three pieces. We have the joiner piece. So we wanted to make sure that the onboarding was still compliant. So we have a dispatcher. They work for us in transport management systems. They create these trips and put them onto the carrier platform.

That carrier platform is actually integrated with our single sign-on platform. We're using PingFederate. And the Ping stack there, it's connected to our IGA. So once that person has got a session, they can use the application, transport management, and they can create a trip. The first thing we have to do is check, is that person or is that application that we're getting this request from allowed to create the trip?

Of course, we want to be sure that we're doing security. So we actually have created our own second IDP, specifically set up for things or the identity of things because the use cases are slightly different. The attributes are slightly different. Lifecycle is slightly different. And the user interface is different. Once that request has been submitted, we use token. I'm going to forget the words. We exchange the token, token exchange, sorry, against the personal to then get ourselves a bearer token, which then can be used against our API.

And if the application is entitled and we verify that the token is still valid, then we can create the identity. There's quite a lot of complexity in creating a trip. That trip is nothing more than a couple of attributes. There's no credentials yet. You can't actually use that for anything. And I call that out because I've just clicked and I've moved on to the credentials. And the only thing we've changed is we've got a different API. The process for managing credentials is identical. So we offer four different types of credential at the moment.

We have a static pin that can be used once or multiple times. We have an email TOTP. We have an SMS TOTP. Or you can use your own full-blown identity to actually get access to this trip. And that complexity is all handled in the auth service there with the IoT, identity of things.

So far, so good, quite complex. When it comes to the driver use case, we've tried to deliver a totally different solution. So as I said, we have two channels to deliver the identifier, the trip ID. And we have the credential to be delivered.

Now, for security reasons, actually what this driver gets is a internal trip ID from the driver platform that's associated to the carrier platform. And when they enter it into the mobile app that they should be using, this driver app, that actually checks against the back end to see if this is a valid trip.

Otherwise, of course, if it's just a number or something like that, you can use denial of service. You can do some kind of dictionary attack to see if you can find these kind of trips. So the front end goes and asks the back end, is this valid? The back end then does some work, checks with us and gets some information, gets a bearer token to say that the system and for this trip, we're now ready to do the authentication. And that information is then handed back to the driver app. The driver is then asked to enter their password or the credential that they've got.

So if it's an SMS, they type in their own mobile number, which has been entered out of band as part of the creation of the credential. We send the SMS. They type the PIN number in against the authentication service. And we grant them a session, just like you would with any other application using single sign-on. Everything we're doing here is OpenID Connect standard. There's nothing special. It's just we've turned the concept of authentication around to say it's not the identity as a person that we're finding out who they are.

We're figuring out if the person who's trying to access that shipment actually has both pieces or both secrets they need to be able to view the information. This is, of course, not a good solution for something like financial data. But for what we need to understand, where have you got to be to pick up something? Maybe you need a PIN, or you need some information to be able to gain access to a location to pick up a container or a pallet. This is perfectly sufficient. And it's actually better than what we had in the past.

Now that we have people logged into the app, we now have the visibility that was originally designed from this project 10 years ago. We now have live location data. I've got this on the next slide. I don't know why.

For about, I think it's 25,000 shipments a month at the moment. Wave 1, they want to hit 100,000 shipments a month. And it also gives us a significantly higher accuracy to be able to plan trips because we have expected time of arrival information now. We know where that person is because we can track them by GPS on their mobile device. And we can use all of the modern AI and machine learning and algorithms to figure out where's that truck going to be and when do we send the other truck to continue that journey if it's a multi-trip journey. We also have live data in the system.

We now are able to offer this data through our customers so they can also see what's going on. So just to summarize a little bit what we've done, we did everything to set this up in six months. Like I said, we have a scope in Wave 1 to be able to cover 100,000 trips a month. At the moment, we've got 5%. I expect the number of trips to continue to roll out.

And I'd say the positivity of this is that the engagement with the business has already started that we've got four additional ecosystems in land transport and the first discussions in other areas of contract logistics to integrate exactly the solution for the use case which has had a very, very low level of assurance necessary for the jobs that have been executed. So I'm not sure if anybody knows in the logistics industry, we have a very, very high level of agency.

That's basically you ask or you contract a company to just provide people to be in a warehouse to do things like go to a shelf, pick a box, scan it, walk over to a dock, put it down so it can be put onto a truck. You don't need a high level of education to be able to do that. And this is the perfect scenario where we're able to engage and get people onto the shop floor to work and be efficient without having to go through onboarding processes, trying to find a username, go and set a pass with its eight characters. They've got gloves on. They've got hard hats on. They've got other kind of PPE.

And then they can't use these tiny devices with fingerprints because they've got big sausage fingers. They get frustrated. When I was actually doing some of the analysis for this, I saw two of these devices be actively tested from certain heights because people were getting frustrated with this. It's just not fit for the purpose that is necessary on a shop floor. So as I end, I would like to, and I'm going to try and be on time, I'd like to kind of reflect.

We started originally when we first engaged with these colleagues to modernize our carrier and our driver platform to just roll out the classic identity. It's a user. It's a person. It's a real person. And they all have the same level of assurance necessary. But as soon as we saw that friction from the business, then we looked at ourselves and we really asked, is that necessary? So I don't know who in this room has thought about it. But my closing question would be, what assumptions are you making in your identity landscape that might not necessarily be fit for purpose? Thank you very much.

Thank you.