Okay, so many of you know me, many of you don't, I suppose. My name is Heather Flanagan. I'm the Principal of Spherical Cow Consulting, and I either work for myself as an independent or I work for everybody. It sort of depends on your point of view. But the awesome thing about this presentation is that I'm not actually working for anybody on this one. This is coming out of my own observations and my own opinions from being, like, down in the weeds for the standards development process.
So if you're kind of expecting me to really sell you on verifiable credentials because they're awesome, you might want to go to another session because that's not actually what this is about. I mean, there are reasons to use them, certainly, but I don't think they're a ubiquitous solution in an enterprise. So what I'm going to cover, right, is I want to set those expectations. I also want to make sure that we all have a common definition for when I say verifiable credentials, what exactly am I talking about? Go through some examples where they work.
Go through the appeal of the tech, you know, why they're sexy and why they aren't the thing that you would use everywhere. So I want you to go away from this session with a little bit more knowledge to ask some pertinent questions as to when and where this might work for you. So I deal with a lot of words on the Internet. I'm a very avid blogger and, of course, being a standards person and actually a professional copy editor, words are very, very important. And the whole verifiable credential space irritates me so much. Because you may hear them as verifiable credentials.
You may hear them as digital credentials. You may hear them as verifiable credentials with, like, capital letters. Or maybe it's verified digital credentials. All of these things basically mean the same thing, essentially, unless you're talking capital V, capital C, at which point you're specifically referring to the W3C standard for verifiable credentials. Great. I like NIST's version of the definition of what are these things that we are talking about. Because they are simply cryptographically verifiable digital representations of credentials and their attributes. There we go.
It's the fancy math that really makes it. So I should do that. Ha! I forgot this button. Yay. Okay. So what makes verifiable credentials super sexy? There's a lot.
I mean, there's so much promise. But what makes them a hurdle? We'll get to that part. But what makes them sexy is you're going to have a much better user experience. You've got all the promise of privacy and the less leakage of PII. Isn't that fantastic? There's so much more security involved where you can trust this because math, magic math, will do this for you. So it's great. It's beautiful. It's also not quite fully baked yet.
I mean, you actually have a lot more stakeholders involved. And I'm not just stakeholders within your enterprise. You've got a whole ecosystem that has to get on board with being able to use these things. You've got, you know, whoever's issued it, do you trust that or was it something maybe you issued yourself? But if you issued it yourself as an enterprise, who's actually willing to consume it? For that matter, what are you willing to store it in? What do you trust? And that's not all really there. So the interoperability is interesting because the ecosystem hasn't fully evolved yet.
And that means when you're actually trying to make the case for, no, in some cases this would be really useful. People will say, and how much is that going to cost and what does that save us? Making that case is actually a little bit hard right now. You're depending on a whole network to actually appear fully formed from someone said.
So no, it's not really all roses right now. You're going to need to think about, well, yes, I have an existing infrastructure. And you could say, well, it just needs another layer of abstraction. That'll solve it. Do you have VCs over that? Let me know how that works for you. So a bit of your infrastructure will almost certainly have to be overhauled, right? You're going to have to coordinate across potentially different departments because, for example, we'll get to this, one of the areas that this could be useful is with HR and travel.
But that's probably not where you work when you might want these used. So you're going to have to do so much more coordination than you've had before. And it is an interesting cultural shift to be able to say, you know what, I am actually willing to trust something that isn't me.
And me, in this case, being the legal entity that is your enterprise. And if you want to say it's standards based, okay, that's a triggering term for me because I immediately want to know what standards are you talking about? Who developed them? Are you talking lowercase standards as in just best practices that sort of seem vaguely kind of correct? Or are you actually talking about something that went through an open consensus process and has been actually tested in the wild? I notice that isn't on a lot of marketing slides. They just say standards, which is fantastic.
So sometimes a spreadsheet might really be all you actually need. So your trick is going to now be knowing when and when not to use it. This is the critical return on investment lens. You've got the cryptographic assurance, really powerful, really cool, really expensive, either, you know, not necessarily in immediate money, but possibly in, well, yeah, but you're going to need stronger devices that are able to handle that computational power. Maybe it means your entire workforce will need new phones. Who knows what that's going to look like?
But there's something interesting there to consider when you're putting this all through the rigor of, is it the right decision for your enterprise? If you only actually have a few systems that are experiencing friction, if things actually work for you, if it works, don't fix it, right? That's kind of an important thing to think about as well. Maybe you're a company that people don't travel. That's not your industry. Well then the travel use case, it doesn't matter. You're not going to deploy that, you know, for the handful of executives that might be on the road.
It's just not a blanket solution for everything you want to do. A lot of our identity problems in the world have nothing to do with the credential that you're using, right? They have everything to do with the process behind it.
And again, that's not really a technology problem as much as we're largely technologists in this room and we want them to be technology problems. We like solving technology problems. That's not the problem that you're probably most up against in your organization. Okay. So why are we still talking about this then? Why would you actually want to do this? I have three main reasons that I think you would probably want to do this, right? You are seeing some interesting shifts globally around privacy regulation, even in an employer and employee circumstance, right?
So that's probably making organizations think a little bit harder about what they're using, how they're using their employees' data, where they're sharing it with, that kind of thing, right? We are seeing interests from vendors and governments who, rumor has it, for example, that in the EU, the next wave of large-scale pilots is going to be about business wallets and legal entities, right? Won't that be an interesting space to say, well, what does that mean for my enterprise? I may be in a scenario where my government is now expecting this kind of thing.
So yeah, okay. You should start thinking pretty hard. And there is a growing push to reduce your PII exposure, even, you know, with your employees but your employees do interact with the rest of the world. So you might need to do some hard thinking about, okay, maybe we have to be stronger about what information we release, okay? So the use cases that I think might justify the pain of trying this, this means they won't be blanket across everything. This is what I think. These are the specific areas where you might play around with this kind of thing.
So what all of these have in common is that the friction is high. You are looking at some pretty interesting expense problems if you get it wrong with what you're doing now. So let's talk about employee verification at hire. How many of you have had to hire employees in your career? There's usually like a big background check that you've got to do and there's all these things that take sometimes weeks to complete because you're trying to avoid fraud at several levels, right? Is this person from some country in Asia, perhaps, that shouldn't be hired by you?
You know, there's a lot of employee verification. Wouldn't it be nice if your enterprise actually knew how to consume verifiable credentials, magic math, right? And be able to say on the spot, yeah, actually this person is who they say they are. They have the credentials that they've asserted they have. They are a citizen of a country I'm allowed to hire from. Suddenly that whole area of friction kind of evaporates. That's really cool. The second area that I think is very interesting is travel.
Now I personally travel more than anybody really should and I have these great conversations with flight attendants that say, wait, you're on the planes more than we are. I'm like, yes, I know.
That said, if I actually worked in a traditional company, you know, many companies have roughly 10 we'll give ballpark number, 10% of their employees might travel, especially if they're a big enterprise. How does that work?
Oh, we use Concur. It has all the policies in there.
You know, nobody likes that solution. I've never talked to anybody that actually likes using a platform along those lines. Wouldn't it be great? If you actually had a credential issued by the enterprise that included what this employee could do, what, you know, what were their spending limits, what chains were they allowed to go to such that if they were on the road and something actually happened and they had to make an on the spot change, they could just do it because they had it in a way that everybody knew how to trust on their device. Also pretty cool future.
I think there are short-term authorization possibilities, those moments where you need the contractors or whatnot to have short-term access to a building or something along those lines. I'm going to go a little bit more into that one because I've had some lovely conversations that involve not enough alcohol about that authorization thing. Because they're like, wait, no, we have access control stuff. And it's really cool. Because we do, you know, now just pick your BAC acronym of choice, right? We have all of these things. And you know what?
The RBACs and PBACs of the world are fantastic under certain constrained circumstances, right? If you own the identity store that you're dealing with, great, lovely. I'm sure that's going to propagate properly through all of the systems you have. What could possibly go wrong? Everything might be within a single system. They all know how to consume your various access control mechanisms, and that would be great, too, right? Everything might be calculated at runtime. Fantastic. Everything is online. Everything is working.
And you've got a whole lot of tight coupling of your integrations, if that's the case. And it may well be. I say it with a little bit of sarcasm because I used to work in higher education, and I can tell you right now that's not what it looked like. But maybe it does look like that for you. And therefore, those are perfectly valid solutions in your environment.
But maybe, just maybe, you're in a situation where you've got a lot of externalized situations going on, where the thing that has the information you want may not be something that you yourselves maintain. Or you know, you are ready to issue the thing because you need to interact with external parties. But there's these possibilities of, yeah, but it's not as central as maybe you think of it, as maybe your architecture assumes it is. If you're designed for cross-domain work, that's pretty a big deal, too.
Now, this one actually creeps in a little bit where, you know, cross-domain work might still be within your enterprise. That's called mergers and acquisitions, where it's one company with lots of different components that may not even have the same domain name yet nor the same IAM infrastructure or whatnot. So that's a really long way of saying friction right there. If your access decisions actually in some cases, as with travel, are things that were all predetermined, why not put them in a verifiable credential? That could actually solve some really interesting problems.
You don't need a live lookup in that moment. So great, this could speed up some interesting processes. If everything is already not as tightly coupled as you would like it to be, if you're subject to a whole lot of mergers and acquisitions in your particular field, if you're seeing a lot of friction with your employees and what they are trying to accomplish that involves access, maybe VCs are an option for you. So where do you want to watch for interesting patterns?
Where would you say, OK, so all of that, what should I be thinking about in my enterprise to say this would be a good and useful thing? Well, one, please don't say you're going to try and roll over your entire infrastructure to do this. That's a very bad idea. Don't do it. But if you can think of some pilots with a limited scope, obviously it's the right place to start. It's always the right place to start. But especially here when you're mucking around with people's identities.
If you do actually deal with a lot of federated models and things that are starting to become these kind of federated issuers, if you have to deal with a lot of government identities in Europe, for example, hey, that would be a great opportunity for a pilot there as well to learn how to be a verifier. And if you are thinking about a strong user experience investment where you might even want to manage the wallet itself, this could be a thing that you consider also.
So a couple practical steps, pick that use case where the friction is already irritating the ever-loving heck out of you and your employees. Start with HR adjacent areas. That's often where you're going to find a lot of friction. Not saying HR is deliberately evil, but yeah. They have different concerns. Test a couple of very limited, maybe you have one-time access things for your contractors. That's going to allow for some interesting internal authorization models. Play with it around. When you're going through all of these, the question, of course, to ask is what could possibly go wrong?
And if the answer is not all that much and you've got some good backup processes, play with it. It's good. One particular note of where, okay, we have we are willing to issue verifiable credentials, but we don't like big tech. We don't want to trust it to the phone's wallet because you have reasons. There are actually even options for that. I don't know if you all are aware of those. The Cyrus Foundation has some nice wallet architecture that's open source and based on consensus-driven standards that actually are standards, and I like them very much.
Anyway, but that's something that you could actually download and build in your organization where a lot of this work has already been done. It's already based on things like some of the FIDO specifications. You can touch this at pretty much every layer you would want to.
So, yeah, be strategic in what you're doing. Be sensible in the scope that you're doing it in, and you're going to have to do probably some education because if it's too easy, people will be like, was this actually secure? So those are all messages that you'll want to send and what you'll want to think about when you're trying to understand the fit in your organization. I am a much better writer than I am a speaker. And next. There we go. I wrote a blog on all of this. If you would actually like to read this in a much more coherent format, then you would hurt it. I wrote out the URL.
That's what the QR code goes to. I hate QR codes with a passion, but I didn't know how else to get it to you. So read it and enjoy. Thank you.
Yeah, thank you very much for these insights and a very interesting topic. The thing is like the last slide, yeah, Rekha remembered me so well about the IAM projects. Just because a tool offers, it's not a perfect fit. Find a solution. I love it. To adapt it when it actually fits. So thank you very much. Any questions from the audience? Yes. One here. Do I have one, any real project about that someone have done this, any company? I think some have. What I would do to find out more about that is to go to, frankly, just find like a Microsoft rep.
Because they are building in their infrastructure the ability to create and consume verifiable credentials and just ask them if they're allowed to talk about that, who's using it. Because I understand there are. But I don't have the names off the top of my head. So that's Andy Hindle. Andy Hindle just said, for the sake of posterity, talk to him about that. And there's some interesting sessions at Identiverse that will go into this with examples. Okay. Okay. I think. And I think. Yeah. Fourteen. Thirteen. Twelve. Stress. Stress. Thank you so much, Heather.
I was wondering, on slide nine, you had those three sort of like use case, or you say like employees, travel, and. Authorization. Thank you. How did you come up with those? Because I believe that you have a lot of knowledge and you've seen a lot.
Like, do you see a lot of friction in those particular cases, or was it, like, yeah, what is the. So quickly putting on the hat of IDPro, how many of you know IDPro? Not as many as you should. It's a professional organization for identity and access management practitioners, and I'm the executive director for that. And the Slack instance, it's what they talk about in some of the channels. That's what they're talking about in terms of the friction that they're seeing and the friction they want to fix and that they think they can. Yeah.
So for those three examples, you see particularly high friction, right? Yeah. Yeah. Yeah. Thanks. Okay.
