The transcript revolves around a presentation about customer identity management, with a focus on simplifying user experiences through effective and flexible identifier choices. Initially, the presenter reflects on updates made to their slides with assistance from the IDPro community, emphasizing the importance of selecting appropriate internal and external identifiers over merely using email addresses. Using a variety of personal anecdotes, the speaker illustrates the potential complications of traditional username schemas, especially for users from diverse cultural backgrounds with longer names. The core argument revolves around user choice; individuals often adopt simpler or more meaningful identifiers, akin to the way characters introduce themselves in literature. The emphasis is on not conflating user IDs with complex internal technical identifiers, given their separate functional roles in enterprise identity management systems.
The discussion highlights significant identity management challenges in B2B and B2C contexts, particularly concerning systems that depend on email addresses for user identification and authentication. The speaker points out the limitations of relying solely on emails, which may not be universally applicable, especially in sectors like plumbing and mechanics where digital practices are less entrenched. Alternative identifier strategies, such as using mobile numbers, are proposed to address these gaps. The speaker also advises against solely utilizing usernames as emails, stressing the importance of distinguishing between login identifiers and communication handles. Insight into adapting identity management solutions to antiquated business practices includes employing personalized strategies and exploring non-digital communication methods. Ultimately, while highlighting the necessity for careful planning and strategic implementation, the presentation promotes understanding of identifier semantics and user-centric models to improve identity management effectiveness.
May I get a picture of all of you? So just showing that the whole Scientropic seems to be... Am I? Is that one on? Mic?
Yeah, mic check, mic check. Ah, now it works.
Okay, great. So, first of all, thank you very much to André for that great presentation. I learned a lot. I found that very, very entertaining and informative. And I must say that doing this in a B2C environment, where you have to distribute any kind of keys beforehand, I know there is a vendor up there who does those hardware tokens and does preceding on a large scale for it. And I think they are also a customer of André's organization. So maybe you should go up to them.
But yeah, I updated my slides just two hours ago because I had a little help from my friends at IDPro, which I really, really appreciate. Who of you have heard of IDPro? Who is a member?
Oh, come on. Sign up. It's really, really great. I just love being part of that community. And that brought me to the point where, due to the feedback that I got, I should amend my title a bit and not just saying Customer Identities without Email, but rather explaining what I mean by that. And that is choosing the right internal versus external identifiers for our users. So another great partner in our IDPro community came up with something like this in 2019. And I completely stole that.
Who says, call me Ismail, one of the greatest opening lines in literature ever by Herman Melville in his book Moby Dick. So the narrator introduces themselves to the reader with that famous quote here. So our friend Ian Glazer used that as a starting point for a great keynote 2019. And I completely admit that this talk is sort of a ripoff. Who has attended that keynote back in 2019?
Okay, so I'm happy that I announced it. Two people would have else called me a plagiarizer. So I'm happy that I got that out. So who remembers Filippina Lana? The two of you. So first letter, first name, last name. Filippina Lana. I practiced that a lot to speak it that quickly. It's a common way of providing users with a username.
For me, it would be S-Rohr. You know, first letter, first name, S, last name, R-O-H-R.
And we, as an enterprise, went with that scheme. And funnily, most of those were quite short.
So S-Rohr, R-Baum, T-Hinle, R-Niegel. They were really, really short. I see we have some people in the audience from other cultural backgrounds with much longer last names. That can be quite long. And I don't know if my username should be J-Subramanian. Because it tends to get long. And if I only have a small community, well, not so good. So you could call me the Adadibia guy, because that's the moniker I choose for myself. Andrei was one of my victims 20 minutes ago. He is one of the recipients of the famous Adadibia.
And if you don't know what that is, just look that up on LinkedIn, on Google, or whatever. So other people would know me by my nickname, Basti, from childhood times. Others who played Counter-Strike with me would know me as Veeing, because I'm a virtual engineer. That was a moniker I choose. And sometimes people just tend to think I'm Jeff. I'm definitely not Jeff. I was just able to get his badge last year during Adadiverse, because I wanted to get in somewhere where I was not supposed to be. What does that all have to do with usernames?
Oh, well, it's about user choice. The narrator of Moby Dick chose to introduce themselves to us as Ishmael. So some of you may have chosen to do the same, because they didn't like their name Maximilian. And they would just say, hi, I'm Max. They wouldn't like you to call them Robert. Just call me Bob. It's about choice. It's about user experience to make that happen. So let's dig a little bit deeper into the topic of the external identifiers. Your user ID, the thing that you identify yourself to your system with, well, it should be easy for the person using it to remember.
I still remember my username at Siemens 25 years ago to be DE200B60. I know that my username at, I don't know, Volkswagen was DKX73V. But I'm just a nerd, so I remember those.
Of course, I would be much better remembering Bus URV, because that's what I chose for myself. So maybe, maybe, I should be able to use a change option for that name if I want to change it. It should be unique inside the realm that I'm using it in.
You know, John Doe or, in Germany, Markus Schmidt might not work so well. You all know that.
Suddenly, you are Markus Schmidt, too. Well, not so nice, but it happens. The most important part, though, is, and this is why it's so important to talk about it, it should not be equal to the technical GUID, to the technical internal identifier that you use in a complex SIEM scenario. Most of the projects that we were dealing with in the last five, six years were spanning multiple different application systems, mergers, whatever. And they all had their unique naming schemes. And some of the customers who enrolled for that tool used that username. And over there, they used that username.
And we all know how that messes up if you want to sync them. Does not work that nicely. So keep those separate. Have some sort of technical alphanumerical string that the user does not even need to know for you to internally sync it. And if you're giving the user the opportunity to change it or to make anything else out of it, well, maybe you should be able to validate it. And this is a little bit problematic if you do not have a mode to connect to the user, to ask him back.
So naturally, many of the B2B, B2C scenarios allow you to use your email address, sometimes your phone number, as the username. Well, that's OK. But you will have a different range of level of assurance if that's really true. And that brought me to the point where I really needed to amend my slides. Thanks to the feedback I got from the Addy Pro community, we really need to understand and separate that you can use a mobile phone and an email address, both as a log-in alias, as an authenticating mechanism, and also as a communication handle.
And especially when you are handling content, that is really, really, really important. So there are semantic differences between the usage of a phone number as a log-in alias, as an authentication mechanism, or as a communication handle. And we need to be aware of that. So as my talk is all about email identifiers not being used, well, it is what we are using. It's what comes up every day.
Email, email, email, email, email. And that's quite a lot. Why? Because email, using an email address, is such a nice thing. First of all, we can do home realm discovery. Everybody familiar with home realm discovery? It's when you log into your Azure stuff, you only put your email. And then if you're a corporate customer, it redirects you, because it enables federated log-in. It's such a nice thing. They just identify the domain of your email, and off you go to your federation partner.
Also, it enables you to do double opt-in. You have to prove that you really want to work with me. You get an email.
Yes, you answer that one. And I know, now I have your consent. I can use your email address and do business with you. Same goes with the B2B customer assignment. If I am shopping for electronics parts, there is a big difference if my username is sebastianrohe at siemens.com, or if it's sebastianrohe at bosch.de, because it will say, OK, I am shopping on behalf of Bosch, or I am shopping on behalf of Siemens. So we're simply used to it. Unfortunately, email is not always that great.
So people, including myself, sometimes get locked out of their email accounts, especially if you are in a situation where you do not that often use that. So your utility provider, how often do you log into your utility provider's systems?
Once, twice a year? And maybe you registered with an email address that you no longer have access to.
Bummer, right? Some companies do not provide email. I'll get back to that. And some people don't even have email addresses. Go to developing countries. They all have a mobile phone. They have a mobile phone number, but not an email. Ask my daughter. Two years ago, she said, email. I don't have an email there. What's that? What do I need it for? I have a smartphone.
So yeah, well, OK, we registered. Oh, OK, I see.
So no, that's not a thing. And yes, shared email, get back to that, is a thing. Just imagine you are now doing business, not in the super-duper high-tech way, but actually with brick-and-mortar shops. Imagine you are Peter the Plumber, and your email address is peterplumber at gmxnet. You run a plumbing shop. You have a few employees.
And well, unfortunately, you never invested in a website that is Peter Plumber's paradise common domain, so you don't have emails for all your employees. It's just that one shared GMX address.
And yeah, maybe, just maybe it's not only used for business, but he's also doing personal stuff with that. And password resetting and those kind of ways gets a little bit difficult. Just think you are Mike the Mechanic. You are a car mechanic, and you happen to be now a franchisee of Cameron's Car Parts Coral. And you have, again, a few employees that work for you, but your franchise partner only provides you with a location email. There is no such thing as a personalized email for all those. So no personalized accounts for the users.
And still, there are thousands of euros of car parts being ordered every day. But you can imagine there's some problems with that, right? So you could say, OK, brick and mortar trades are lagging behind. But to be honest, have you tried recently to reach one of your finance providers and really talk to a human being because you got locked out of your credit card app?
Hard, right? Because you have to deal with those nasty call center AI agents now, right? So no email, no worries. Craftsmen are really, really old school. They are being served by traveling salesmen still. It's not like you go there and say, I want to be your customer.
No, no, no. The salesperson comes to you and says, I see you're doing good business. Maybe you want to shop for your plumbing equipment or your car parts with us because we are one of the major retailers. So those shops are vetted carefully and chosen by merit or by credit score or by whatever. There is no such thing as self-registration. There is a customer representative that will grant you access. And they will set a username for you. And if you want to call Customer Care, yes, they do have that. And it's a real person picking up the phone.
And they know who you are because they have that computer telephony integration that my guys worked in 1998 on. There is a real person, and you can talk to them.
And yes, they will even reset your password. They will give your password to you, much like we had in the keynote of Cedric this noon. So why should I even send an email to Mike or Peter? We can even call them. We'll just go there. We'll pay them a visit.
So yes, brick and mortar, plumbing, car mechanic business is still very different. And we ran into that exact problem with two projects in the last 24 months. And the customer sales organization, no, no. Our customers don't have emails. We can't do that. Big hint. Most of the SIAM solutions out there require you to provide an email address because you want personalized access. And even if there are five users shopping for car parts, usually with a SIAM solution, you want them to be individually identifiable. But if they only have one email address, quite hard to do. So KYC is an issue here.
And that becomes an issue for our SIAM implementation. But as we all know, well, SIAM implementations are not done in a day. So we can use that time, time to induce change in the brick and mortar shops. Right. You as the guy selling the mechanic, the exhaust pipe, you tell them how they run their business and what they should use as an identifier. It's just not so easy to digitize plumbing just because you want to sell them stuff. So I can only recommend, carefully plan out when you're going to sell B2B to those old school enterprises.
Make sure that you kindly build them a ramp while you're building your SIAM solution and you're preparing to migrate your old user database, asking them, well, could you not ask those guys to provide their personal email address? Because, well, we do have that app. And I know that some of your folks are using that app. That means they have a smartphone.
And hence, they must have an email address. Because no email, no smartphone usage, right? So carefully communicate.
Maybe, well, as being the organization that tries to implement SIAM in such a B2B scenario, instruct your sales team, your traveling salesman, to talk to them and kindly ask for emails and chances for them to at least provide a few numbers of emails more so they can gradually provide their employees with those emails. Yes, prepare printed letters. Our customers did that. They sort of sent printed newsletters out.
Oh, by the way, we're going to change the login for our beloved portal here. It's going to require you to provide an email. So please do that. Advertise the changes. And even talk to them in settings like this. Not only the identity. People do meetings like this. There's exhibitions for plumbing, for electricians, for everything. So do that. And also tell them why you're doing it. And in most of the cases, it's just fraud, right? Because you can't do KYC. There's one email used for all the orders.
You've got to explain to them why suddenly, after 20 years, well, maybe not, like 15 years of doing online business, they suddenly need to have one user identity per person working in my mechanics garage. And remember, as an option, there's always telephone. Some of those do.
Skype, no more. I hope they adjusted it. I took the picture before Skype officially went offline. And in the end, we got saved in that one particular project very shortly before we had to give up. Because the vendor that was chosen just provided an update that suddenly you could migrate user databases without email just by providing a username. And you could then add the email. I'm running out of time, so I'm just jumping to that one issue that you have. Just remember, there is a field called username. And usually, there is a field called contact email.
If the username is the email, OK, not an issue. If you change the first, then you should set your system to change the second too. But if those are different, you migrate the user database that has non-email usernames in it, and then the customer chooses to add their email, you need to pay attention that you update both the username and the email on that. So remember, if you're using emails, if you're using telephone numbers, as the user identifier, as the username, the semantics really, really are important. So let's discuss. I think I got like 30 seconds left. Thanks for being here.
Thanks for attending. Looking forward to your questions. Thank you.
See All Locations
See All Locations