Paul Ashley: Will Consumers Pay for an Identity Product?

Today’s guest is Paul Ashley, CTO and co-CEO of Anonyome Labs. Paul starts by talking about how the erosion of privacy online and the rise of data brokers and surveillance capitalism led them to create their IDtech product MySudo. MySudo is a privacy application that allows users to create secure digital profiles, or personas, with unique disposable phone numbers, emails, credit cards, and other identifiers to use across the internet.
With hundreds of thousands of users, MySudo has defied conventional wisdom that consumers won’t pay for identity services, making it among a handful of successful, sustainable IDtech businesses. Paul breaks down how they’ve succeeded by taking a practical product approach and by talking about use cases rather than features.
Our conversation naturally led to a discussion about how decentralized identity fits into their roadmap, which Paul called the biggest privacy breakthrough of the next decade. We talk about some of the opportunities and challenges in this nascent space, including navigating the complex technology landscape, how to find good problems for decentralized identity to solve first, and how their experience building what some would call a “web2” identity product is informing the way they tackle the UX of verifiable credentials.
This is a conversation that will interest anyone who has a passion for privacy and safety online and will be very insightful for anyone building a consumer identity product.
To learn more about MySudo and Anonyome Labs or to get in contact with a team member, visit https://anonyome.com/.
Download MySudo on the Apple Store. Download MySudo on Google Play.
Reach out to Riley (@rileyphughes) and Trinsic (@trinsic_id) on Twitter. We’d love to hear from you.

Full Transcript

Transcript lightly edited for clarity.

Riley Hughes: Welcome to the Future of Identity podcast, where we talk to the people building the identity tech products of tomorrow. I’m Riley Hughes, co-founder and CEO of Trinsic, and we build infrastructure for launching identity products. Today’s guest is Paul Ashley, CTO and co-CEO of Anonyome Labs. Paul starts by talking about how the erosion of privacy online and the rise of data brokers and surveillance capitalism led them to create their ID tech product, MySudo, a privacy application that allows users to create secure digital profiles or personas with unique disposable phone numbers, emails, credit cards, and other identifiers to use across the internet. With hundreds of thousands of users, MySudo has defied the conventional wisdom in the identity space that consumers won’t pay for identity services, making it among a handful of successful sustainable ID tech businesses. Paul breaks down how they’ve succeeded by taking a practical product approach and talking about use cases rather than features.

Riley Hughes: Our conversation naturally then led to a discussion about how decentralized identity fits into their roadmap, which Paul called the biggest privacy breakthrough of the next decade. We talk about some of the opportunities and challenges in this nascent space, including navigating the complex technology landscape, how to find good problems for decentralized identity to solve first, and how their experience building what some would call a Web 2 identity product is informing the way they tackle the user experience of verifiable credentials. This is a conversation that will interest anyone who has a passion for privacy and safety online, and I think will be very insightful for anyone building a consumer identity product. We hope you enjoy the episode, and now on to my conversation with Paul. Welcome, Paul.

Paul Ashley: Yeah, thanks, Riley. It’s a pleasure to be here.

Riley Hughes: I would just love to start the conversation by asking you to tell a little bit of the founding story of Anonymi and how you got to be where you’re at today.

Paul Ashley: There’s a bunch of us who had a long history in identity and privacy and security, and we saw this real growing problem even in 2014 that people, just general everyday users, were completely losing their privacy. The pendulum was swinging further and further away from them, such that everything they did was being tracked, it was being mined, their information was being stolen. So even in 2014, the problem was bad, and I can guess we could say the problem is even worse now. And it wasn’t even just the big players like the Googles and Facebooks at the time, but there was just this myriad of data brokers who were out there just collecting personal data and then on-selling it. You could see that the user really had very little hope of protecting themselves. So that was really the why of the company. Why did we want to have a company? We wanted to provide technology for everyday users that could provide them greater privacy, greater safety, and security. And our mission was to build product, to be a product company that delivered product in that space. So that’s the history of Anonymi.

Riley Hughes: So tell me about the history of the products. When did those enter the picture? What were the products, and how did they evolve to what you have today, which I think we’ll probably spend most of our time talking about, the MySudo product and the rest of the platform that you’ve got.

Paul Ashley: Imagine there’s five of us in a single room, and we’re saying, Well, how are we going to tackle this? And we realized very early that it was an identity problem. And the identity problem was that when you went out into the world and did different things, it’s always you with the same identifiers, and it made it very, very simple for the trackers to be able to follow you around. So you go to one website, we all know the story, and look at a red shirt, and then you go to the other website and there’s a red shirt ad pops up. That was because users were using their single real or their legal identity just to do everything. And then if there was sale of that or theft of that information, the user was in a fair bit of trouble. So that’s a long way of saying this is when we came up with the idea of a persona. And we use the term pseudo. So you say, why is it called MySudo? It’s because of pseudo. And where did the term pseudo come from? Well, pseudo came from pseudonym.

Paul Ashley: So we came up very early with this idea of compartmentalization, that when you’re online in the world, we can’t all go and live in a cabin in the woods. We all want to go and do all those things online, that you would compartmentalize what you’re doing. So you’d sort of have one digital identity, and that would be your shopping, and another one that was because I want to sell stuff. And I have another one because I want to go dating with that one. And I might have another digital identity, and that might be more towards my legal identity for things like booking airline tickets. So the idea is to solve the problem, to say, well, maybe users should be able to go out and pick which persona they’re going out with, and then with that persona have a whole lot of attributes. Well, what if that persona had its own phone number and its own email address and its own VPN profile? And what about if it had its own virtual credit card? And what if it had its own browser? All the things that you need so that you can be different in situation A and situation B.

Paul Ashley: So, for example, I want to be a certain persona when I’m shopping, but if I need to go and do some research, maybe I’ve got some health issues and I want to research that, I don’t want to be the same persona again. I want to be a different persona. So we can’t link those two things together. That’s probably the step between the why and getting to the first application was we came up very early with this idea of multiple digital identities or multiple personas, which we call pseudos. And then the next question is, how to deliver that out to a normal user. So what we said is, well, why don’t we start with mobile apps? And that was where we came up with our first app called PseudoApp. The idea there is it was just about the communication for a persona. So you could create multiple personas, and each of them could have a different phone number, different email address. So, for example, if I’m calling my plumber, will I use my mobile number? If I’m calling a car dealer. why use my mobile number? Why not use a different number? So think of SudoApp as about communication.

Paul Ashley: There was another thing that we realized is there’s two types of communication. If you look at apps like a Signal or a WhatsApp, they’re primarily what we call in-network communication or within the walled garden. So you and I, Riley, can only communicate on Signal or WhatsApp if we both have Signal, we both have WhatsApp. Now there’s advantages of that. You can get end-to-end encryption. So I can encrypt my messaging, I can encrypt my voice calling, I can encrypt my video. And that’s where sort of Signal and WhatsApp finishes. It’s about me talking to friends or maybe some work colleagues or something, but it’s all about we both have the same software at both ends of the pipe. But what we realized very early is it only solves half the problem. It’s the out-of-network communication, which is just as important. For example, I want to communicate with a car dealer, and we know what happens as soon as you go to a car dealer, you’ll never stop getting called. They’ve already sold your information and other people start calling you.

Paul Ashley: If I’m then talking to a car dealer, maybe I spin up a new one and just use it while I’m buying a car. And once the car’s bought, I just delete that number. So there’s no more trail there. The other big one early was people said about dating. They’d be in some sort of dating app, but then at some point you’ve got to step out of that to the real world. And then you say, well, now I’m going to give this stranger my mobile number. With that mobile number, they can go and find out where I live and do all those other things. So we thought straight away with SudoApp, we need to cover both cases. We need to cover in-network and out-of-network. And the way you see in MySudo the difference is if you’re in-network, it has that little lock to say end-to-end encrypted, both ends got MySudo. If you look at outer network, you don’t see the lock because when you’re calling out of network to call someone’s mobile or you’re sending them an email, it’s in the clear. You just have to deliver that.

Paul Ashley: But the fact that you’ve still got different identifiers and different numbers and email addresses still gives you a level of protection. So imagine Sudo App was our first communication app, is showing the concept of pseudos and communication both in and out of network. And so we said, well, the other thing that people kept asking about is the credit card problem. I want to go and go to this bike shop online and I want to buy a part. It’s a family business, they’ve got no security, and they’re probably going to get the data stolen, or if they don’t, they’re probably going to sell it because they can make money doing that. It’s five minutes later, it’s on the dark web and someone’s bidding for your credit card number. So that was the other problem that we were thinking, how to solve that. And, you know, at the time people were talking, oh, maybe it’s cryptocurrencies, maybe we should be putting Bitcoin in the app and things like that. But what we realized really early is that credit card, and it’s still true today, is the primary mechanism for purchasing things all around the world.

Paul Ashley: So we needed to stick with that paradigm. What we did is we decided we’d go down the virtual credit card path, which is we can allocate you a credit card number with the number, the CVV, the expiry date, billing address, all those things that you need to use with a credit card, but they’re virtual in that there is no plastic card behind them, and you can have as many of them as you like, and you can do things like set limits on them, like I can only use this once a month, and I can only use it for $20 a month, and things like that. All the kind of protections you can put on a virtual credit card, you can’t put on a real physical plastic one. And so we had a second app called Sudo Pay. And the Sudo Pay was just about virtual credit cards, and it was about saying, okay, spin up yourself a virtual credit card and go and use that to purchase something on a website, and all of a sudden you’re safer because if that gets stolen and they sell it, it doesn’t kind of really matter because just like your Sudo phone number, you can just get rid of it and get another one.

Paul Ashley: And I just had a friend who, in the last week, said at like two o’clock in the afternoon, and this is in Brisbane, Australia, he’d done a purchase, and 2:30, someone in New York used all the funds on his credit card. And so now he’s in this problem, like he’s got nothing left on his credit card, so he can’t pay any bills. And now I have to go to the bank, and I have to explain that no, I wasn’t in Brisbane, and then at 30 minutes later in New York, the credit card had been extinguished. So that’s the problem we were trying to solve with that. So imagine at that point we have SudoApp and SudoPay, and they’re both in the App Store, and they’re both getting used, and we’re learning and finding out all the problems and improving them. And then we came up to the decision to go, actually, they’d be better together, and that’s where MySudo came from. So MySudo was bringing together SudoApp and SudoPay and adding things like a compartmentalized browser and saying, look, if it’s all in the one app, it’s then sort of covering everything you want to do.

Paul Ashley: MySudo’s been out there for, what, probably three or four years now.

Riley Hughes: Thank you. Yeah, so MySudo is a consumer identity product for creating these personas for people to use throughout their life online. Is that a good summary?

Paul Ashley: Yeah. For example, I have eight different Sudos. MySudo allows you to get up to nine. And so I have one, for example, travel. So I’m heading out to the States in a couple of weeks, and so I book everything with my travel Sudo. So the email address, the phone number that’s used, everything is on that travel Sudo. So it’s not only handy that all of those hotels and flights and everything are using that travel Sudo, but it’s also compartmentalized. So anything they send me all ends up in that Sudo, and so I can go and have a look at text messages, I can go and have a look at the email addresses, they’re in that Sudo. So the compartmentalization also helps you manage your life as well.

Riley Hughes: That’s nice. It’s interesting that this is really how the real world works. I remember a time in high school where, you know, I spent a lot of time at the skate park, and I also spent a lot of time in a club at school. I was in a leadership role in the club at school, and I was a senior in high school or something like that, and so I had people who wanted to come to me for things. And then at the skate park, I rode a scooter instead of a skateboard, so I was sort of the lowest one on the totem pole at the skate park, just sort of reversed from. I just remember thinking, wow, how different. I am a different persona in each of these different places, and therefore I’m treated very different in these two places, right?

Paul Ashley: It’s very true, is that we all have multiple personas in our life. When I’m at work, I’m in my work persona. When I’m at home, I’m my home persona. And then when I’m at my children’s school, I’m the parent persona, and so why not have a persona for their sports and their music and all that? And it’s probably took me about six to 12 months to work out what I needed, but I found it about eight. I finished and I had enough, and I’ve kept that probably for the last two years at eight personas. But that’s the level of compartmentalization that seems to work for me.

Riley Hughes: One of the questions I like to ask whenever I’m thinking about a new technology is why does this not exist already? If this is such a great idea, why isn’t it already out there? But I think in this case, it’s a little more obvious, and you can tell me if you disagree here, but it feels like in this case there are incentives at work that prevent some of the legacy players or whatever from offering out-of-network capabilities or offering personas because they can more easily track and correlate activity across things and better exploit you for commerce or things like that.

Paul Ashley: Yeah, I think so. It’s a logical thing. Why doesn’t Google have personas and things like that? And I think it’s for that reason. I mean, if you look at the world of software, there’s only two models. You get software for free. What it means is you’re the product. They want your information. It’s your activities that is the value to them, or they charge you for it. That’s sort of a concept we had to really struggle with in the early days of SudoApp and SudoPay and MySudo, is which model we had. And we’re like, well, we’re a privacy company. We can never go to exploiting our users’ data. So we only have the other model too, which is we have to charge our subscribers, because otherwise we’re out of business. And so I think the reason why we could do it is because we’re very privacy focused. This was the mission of the company and the mission remains the same now. Even in the enterprise case, it’s always end users we’re dealing with.

Paul Ashley: And whereas I think those companies, we know who they are — the Metas, the Googles, and a hundred others — they love to give you stuff for free if they can, because they want your activities, they want to know what you’re doing, and they want to know where you’re going and do all those things. So if you’re getting a piece of software for free, then think about why it’s for free and what they might be doing to fund that product.

Riley Hughes: Yeah, it’s interesting. I think a lot of the folks that I talk to, or people in the broader decentralized identity world, which is the world that I come from professionally, there is this strong sentiment that you could never charge users for an identity product because people are so used to getting everything for free. I’d love to dive a little deeper into that, but first, you mentioned MySudo has been out there for a couple of years. Could you give me just a sense of the magnitude of roughly the size of the user base, just to give us a sense of the scale of users that could be willing to pay for something like this?

Paul Ashley: We’re really in the hundreds of thousands of subscribers. We actually do have a lot of free users, so you can do end-to-end encrypted messaging, email with it, and you can use the browser, and all of that is free in MySudo. If you’re going to charge, you’re going to build your user base up slowly, but then you have a model where all of a sudden you’re saying, okay, as we build up more users, we’re paying for this app. The app pays for itself. It actually pays for the developers that sit behind it. You know, we have iOS teams, we have Android teams, we have backend teams, and these all people have to be paid. And so the subscription model can allow that to happen. Sure, you might get slower growth, but you get sort of sustainable growth versus you could go really big and be free. But then you’re in a position to say, now how am I going to charge these users? So we took the decision very early to say, look, we think this app is valuable. Subscribers will be willing to pay for it. And so we went down that path and we’ve maintained that path all along.

Riley Hughes: If there were other companies that were potentially looking at charging consumers for a useful product, as opposed to delivering a consumer product for free and trying to find another way to make their money, what advice would you give to them?

Paul Ashley: You do need to have a way to get into the app and to use it free. And as I said, we’ve got four or five features that you can use for free. So you have to do that. And then you do need to have these different tiers. So we have a tier that’s a 99 cents per month tier, quite cheap. And then we have a second tier that’s higher and a third tier that’s higher. And then what we find our users do is they start on that free tier, then they might get a subscription, and if they find that useful and they go, well, actually, I’d like more of these, then they go to the higher tier. And if they still feel like they need more of those, they go to a higher one. So you’ve always got to have a way for people to come in and try an app for free. But over time, as they’re using the app more and more in different use cases, then I think you’re in a position to go, okay, I actually am willing to pay something for this because I’m getting value for it.

Riley Hughes: That is really helpful. How do you help users maybe see the value of the types of things that they could use this for? I could imagine a world where I download the app and I see, oh, I can create a new phone number or I can create a pseudo email. But are there any kind of use cases or tactical sort of tips in terms of messaging to end users that have been helpful?

Paul Ashley: We don’t really talk so much about pseudos. We don’t talk about numbers and email addresses. What we do is talk about use cases. Our number one use case is shopping. Probably our second is selling. Probably our third is dating. And then I’m trying to think what the fourth is, probably travel. A lot of people use it for travel like I do. We try to talk about it from the use case point of view because that’s what’s interesting to users, and we’re putting a lot of work into the kind of onboarding of the app to say, what’s the first use case you’d like to use, and take them down that journey and say, well, to do this use case, these are the three things that you’ll need. So I think the barrier we have is once users come into app, they’ve got to start using it on one or two of these use cases to see the value for them to stay and then use it for more use cases, if that makes sense.

Riley Hughes: Yeah, that makes sense. One path that I’ve seen a number of identity companies either go down or explore is this notion of layering in an authentication product or a— tool into the application. You know, now that these consumers have a pseudo, can they log in anywhere with a pseudo? Can they authenticate themselves with the pseudo?

Paul Ashley: That’s almost its most important use case, right, is whenever I go to a shopping site or a selling site, or your dentist might even have a login for their site, the primary thing you need, right, is a username and password. So we would say, never log in, you know, with my private email address, for example. I’d always create a pseudo email address for that and use that to log in. And so it does help with that login experience, creating a login account. Even doing two-factor with it is really useful. I use a password manager, and I probably have 250 different accounts in there. Almost 100% of them are all using pseudo information. And that took some time because I had to swap out things and change things and create new accounts and all that. So it doesn’t happen overnight. But I would say now, if I was to go through my password manager, I would think the majority of them is using like a pseudo email address, pseudo phone number, all those things that you need when you create an account.

Riley Hughes: I can almost imagine, I guess, a future world where instead of a login with Google button, I see a login with my pseudo button.

Paul Ashley: Oh, sure. And this is when we’re getting more to decentralized identity, which I think is a natural accompaniment to pseudos as well. So let’s talk about the world of login. There really is two predominant methods in the world, right? You’ve got what you call your centralized login. That’s your case where you say, I need a username and a password, and maybe a phone number for SMS for a two-factor. That’s your centralised system. That’s still, I don’t know, 50% or more of all logins, as probably people do that. They may even do more than that. The other side is what they call the federated login or the social login, where I’m logging in with Google, logging in with Facebook, or logging in with Twitter or whatever, and that’s where your primary account is with them, and they kind of single sign you across to this new account. Now, centralised is bad because you’re putting your information all over the place, and I think federated is worse because you’re just giving it all to the Metas or the Googles, whatever, and they see everything that you’re doing.

Paul Ashley: They know all the places you’re going, so that’s even worse. And that leads into why I think decentralised identity is the next revolution, which I think fits well with the Sudo concept as well.

Riley Hughes: Yeah, I would love to hear you unpack that a little bit. To me, you’ve got a product that’s working well. It’s been out there for a while. You’ve been very practical. You mentioned the Bitcoin example, and instead of layering in maybe a cryptocurrency or something, you’ve gone with the credit card route because it’s already widely adopted. Decentralized identity, on the other hand, is not already universally accepted and widely adopted. How do you marry the practical, very sort of tangible use case-driven consumer product that works today with the future vision of decentralized identity, which maybe is still very much sort of playing out?

Paul Ashley: I’ll tell you the history of how we got into it. We came at decentralized identity from the privacy direction, because the way we look at it is users need a tool belt and they need to pull out their different tools. So here’s my Persona-based VPN. Here’s my browser. Here’s my phone number. Here’s my email address. You need all these different tools at different times. And then we saw decentralized identity come along and we said straight away, well, this is a technology that’s 100% been designed for privacy and safety. That was the direction we came at it. We have an office in Salt Lake City, and it just happens around the time that we were looking at it, and along comes a person called Phil Windley. And he at the time, I think, was the chair of the Sovrin Foundation, and he said to us, You guys need to run a validator node for us on the sovereign network. And we’re like, What’s a validator node? What’s a network? and all this. So we started to run a node for the sovereign network, and now we run also one for the Indicio network.

Paul Ashley: We also run a node on the Cheq network, and so we kind of learn in that space also from helping to run those networks. But in the beginning, we actually had another person in Salt Lake, and he said, Look, start turning up to some of those standards groups. So, you know, there’s DIF, Decentralized Identity Foundation, Trust Over IP, there’s the Hyperledger, the work they’re doing with Indy and Aries and Ursa, and now there’s W3C with their credentials. And so we had our person in Salt Lake, and he still does it. He attends a whole lot of these different standards groups to learn and contribute. And then we said, Okay, now we have to look at the product side. How does it affect us? And so we started to look at different aspects of that. So what’s a wallet? What does a wallet need to do? We’d all talked about wallets. We know about our Apple wallets, our Google wallets, but what’s a decentralized identity wallet? And it turns out it’s all about managing connections, and it’s all about verifiable credentials and managing those as well. In some ways, it’s an account.

Paul Ashley: It’s like you go to a website and you scan a QR code, which is an invitation request, and then between your wallet and that site, you establish a connection, and that feels a lot like creating an account with it. And then once you’ve established that connection, maybe give them some information, and you can go back to it because you can go back and use that connection again and sort of be re-authenticated. And it’s all private-public cryptography, so gee, that’s a strong form of authentication. And we realized this is the next revolution about identity management. So, you know, one part of our product development is around building the wallet. I can tell you now, the wallet is a very complex entity. There’s multiple different credential types. You have non-CREDS, you have W3C creds, you have other stuff as well out there. And then you have different versions of protocols: AIP 1.0, Aries Interop Protocol 1.0, then you’ve got 2.0. Guess what they’re working on? 3.0. And there’s other initiatives as well.

Paul Ashley: So the wallet itself is a major piece of development, and we’ve been working on that for quite a long time. Then you look at the other side. Well, we need to be able to issue credentials. We need to be able to verify credentials. And so that side is a part we’ve been looking at for the last couple of years as well. And we’ve looked at all other technologies around that. So we started with learning about it, helping to run these networks, getting in the standards group, and probably the last two years plus, we’ve been focused more on the product development side. We see it as really revolutionary. It might be the most important technology for privacy for the next… decade. So you could say for us, it’s the future-leaning part of the business. It doesn’t mean all the rest of it we’re not working on, but that’s the future-leaning part that says that is the future, we think, and we’re 100% behind it.

Riley Hughes: I’ve noticed something sort of interesting here. I was thinking, this is a conversation I’m going to send to my aunt and my uncle. You know, this is like a very consumer-friendly podcast, very tangibly grounded in use cases and privacy and safety. And then over the last few minutes, we’ve gotten into decentralized identity, which of course is more nascent. But I’m thinking, oh, I’m going to lose them at this part. So I guess, can you map some of these concepts as a consumer product? How are you going to take these concepts to consumers in a way that hopefully will incentivize more of those free users to upgrade to subscription tiers so that they can pay for these services too?

Paul Ashley: You know, I travel to Salt Lake City quite a lot, and I happened after work to sometimes go to a bar. And you turn up to a bar in Salt Lake City and they say, You need to prove you’re over 21. Like, I’m over 21. No, you need to prove it to us. And I say, Okay, what do you need? We need your driver’s license. And they look at my driver’s license and say, Sorry, we can’t use that. It has to be a U.S. driver’s license. Okay, what’s my other alternative? Passport. Okay, so I go, Okay, pull out my passport. See here, you can see it’s me. Oh, we need to take a photocopy of that. And so they go and scan the page, and I’m like, Okay, you’ve now got all this, really, and how many different Paul Ashley passports are out there? I don’t know. There’s these times in your life where you’re exposing too much data about yourself. Whether I’m using my driver’s license at a bar or the passport at a bar, you’re just exposing too much information. What they really need to know is that you’re over 21.

Paul Ashley: So what about if you had a credential on your phone and you could present it, so it’s a digital version of my driver’s license or a digital version of my passport. But we use what we call selective disclosure, so I don’t need to tell you the 20 different fields on my driver’s license. You just need to see two maybe, or maybe three, maybe my photo, maybe my name, and maybe my birthday. Or maybe I could use something even more complicated called zero-knowledge proof and just prove that I’m over that age without giving my birthday. You see what I mean? It’s like I can then go into a bar in Salt Lake City and say, Why don’t you just use these three pieces of information to let me to go into the bar, and you don’t need to know all those other things. I look at it as a really good privacy-protecting technology, and I can see that there’s going to be a lot of government uses for all those kind of credentials—the passports, the vaccine certificates, the driver’s license. But there’s also a lot of uses like, Why can’t your gym membership be on your phone?

Paul Ashley: Why can’t your Costco membership be on your phone in the same way? And a credential that not only you can present, say your Costco, but present to someone else and say, Look, here’s my Costco thing, and I get a discount or something. We’ve got to stop users having, like me, 250 username passwords in a password manager. We’ve just got to stop users doing that. So even just managing the login problem, I think if we can solve that with decentralized identity, I think will be a marvelous thing for the world. So where could we deliver it? You know, we could deliver it into our wallet app, or we could deliver it into MySudo. There’s different options for us, or out to our enterprise customers as well. So there’s many places that we could do it. But at the end of the day, I do come at decentralized identity from that privacy, security, identity point of view. It’s just the next piece of technology, which is really important for the future.

Riley Hughes: Thank you. That is really helpful to close the loop there. I’ll give a little bit of a warning to my aunts and uncles and whomever else is going to listen to this, because I’m going to go back into the weeds just a little bit here. But I’m curious how you see other more modern approaches to public-private key-based authentication. Things like some of the passwordless approaches, things like FIDO or passkeys, and how you see those intersecting, or how these standards sort of play into the story that you’ve painted of authentication moving from centralized to federated to something more decentralized.

Paul Ashley: There’s nothing wrong with those technologies. There has to be a bridge between them. But I think that decentralized identity came up with some technology that the other ones didn’t think about, and I think it’s the wallet. When I look at the FIDOs, the WebAuthn type implementation, I think, you know what they forgot? They forgot to define a wallet. So I can get this key and I might be able to use it here, I might be able to use it on my Apple, but then I can’t move it onto my Android device, and there’s sort of this problem that they don’t have this generic wallet concept in there. So I think that’s a big thing in decentralized identity. The definition of a wallet and how that works, I think, is a really big plus that goes beyond what are some of the things we have now. But I do think that we have to help entities, whether they’re big government or big enterprises, to be able to bridge from the old world to the new world and make it a progressive transformation.

Paul Ashley: So a user comes in in a certain way, let’s say they’ve got a username and password, and let’s try to slowly migrate that user base to more private-public key-based system with a wallet, etc., and get all the benefits of doing that. So I think we do have to have sort of a bridging philosophy for the next probably five or ten years.

Riley Hughes: Yeah, that makes sense. You know, when I think about timelines and adoption and where the state of decentralized identity is today, and where it was five years ago when Phil Windley hired me at Sovrin in my first role here in this decentralized identity world, that’s where I think I met your team. But even thinking back then, and how the space looked then and how it looks differently now, I wonder for ID tech product builders. How would you advise them to think about timing? Suppose there’s somebody who sees decentralized identity as the future just as much as you do, but they’re not sure whether now is the right time to invest in the productizing or implementing these standards, whether that time is now or whether that time is later. And maybe just to add one more element to the question, I think some people get a little bit of standards paralysis. This is a term I’ve heard some of our friends from Indicio use.

Paul Ashley: Yes, yeah.

Riley Hughes: But it’s sort of this notion of like, well, I don’t know if a non-creds is going to be the thing. I don’t know if it’s going to be the W3C spec or the IETF ACDC. ACDCs or the ISO mDLs or the, you know, again, apologies to my aunts and uncles who are listening, but there’s all kinds of flavors of different approaches that are out there floating around. You know, how about you advise somebody who’s a bit overwhelmed by both the timing question and the competing standards question?

Paul Ashley: It’s an excellent question, Riley, because we have to face that all the time. Do we build A or do we build B? So if I look back four years ago, it was very, very, very early in it where we just started to get some networks. We’re just starting to get some standard stuff created. I think we had Hyperledger Indy then and maybe some early Aries protocols and things like that. It was very, very early in those days, and people weren’t really doing decentralized identity projects. Now we know in the last four years, it’s changed considerably. There’s a lot of standards work across Hyperledger, across DIF, across W3C and all these different standards bodies. And the rule I always say about decentralized identity: the more I know, the less I know. You know, I realize every time I learn some more, I realize I’ve just opened up another can of worms and there’s a whole lot of new things to learn. So you’re never really on top of it. You just have to make sensible guesses as you go along.

Paul Ashley: I wrote an article recently on this called The Killer App for Decentralized Identity is Verifiable Credentials. To me, that is the thing that is so unique and so different to anything that’s been out there before, the way that’s designed, that that to me is the killer app for decentralized identity. Then you say, okay, so that’s why we need a wallet that can be able to be issued a verifiable credential, can be able to present a presentation proof it’s called of a verifiable credential. We have to be able to have an issuer, so we’re going to be able to issue credentials, and we have to be able to verify. And so that decision to build that sort of stack and have all that, I think there’s no question. Then you get into the next hard question. Do we do anonymous credentials or do we do W3C? Now, for us, there’s really no question that anonymous or anon creds is better credential technology. It’s totally designed for privacy. It has revocation. It doesn’t carry any identifiers in the credential.

Paul Ashley: It has a whole lot of things which I say, that anon creds standard and implementation is absolutely perfect for anonymity and fits the persona model and having multiple personas, and DI fits very much into that. And don’t be surprised if, for example, you see MySudo pop out with some wallet capabilities. That may happen in the future. W3 obviously could come from a different direction. I think they came from an identity authentication direction versus a privacy direction. So, for example, they like to put the subject DID, which is the person’s identifier, in the credential itself. So if I use this credential at three places, we’ve got a nice tracking identifier for those three organizations. And so W3C for us is not as natural fit. Will we implement W3C creds in our wallet and in our issuer and verifier? Yeah, of course we will, because I think, especially coming from the government side, they’ll say W3C, big standards body, important. We need to go down that direction. But it isn’t designed to be as privacy sensitive as anon creds.

Paul Ashley: W3C, we will hope to influence it to say, look, they do have a section on privacy, but it’s buried way down in the document. So I just think they come from different directions. But will we need to support both? Yeah, of course we will.

Riley Hughes: For people who may be hesitant about investing now, it sounds like the message that I’m hearing from you is that both will be important, or at least in your world, both will be supported, and there will be a place for both.

Paul Ashley: 100%. Again, I’m only just forecasting the future. I kind of see this sort of government world where they’ll go down to W3C, but a lot of private sector work, there’s no reason why they need to go down that, depending on what their requirements are. So I think there’s place for both of them. For you and I who are building product, we have to be able to issue them, we have to be able to verify them, we have to be able to put them into a wallet. That’s just the world we live in. I’m sort of comfortable with that. And in terms of the timing, a thing that I have noticed over the last year especially is all of a sudden there’s a lot of organisations wanting to do projects in this area. I’m glad we got into it four years ago. We have a lot of expertise in the area. We’ve now got two years of product development under our belt, and I feel now you’re starting to see it opening up to real pilots, proof of concepts, and into production. So I think the industry has changed now that there’s a lot of enterprises out there that are saying, actually, this technology does look pretty good.

Paul Ashley: I think I could use it. In fact, I’ve got a use case over here. So I think the timing’s really good. I think the wave is cresting at the moment.

Riley Hughes: Yeah, you mentioned the issuance process, the ability to put it into a wallet, which you described as a very complex piece of software, and I can attest as a company that spent a lot of time there, I can agree with that. And then also the process for verifying that credential and getting all the participants to play ball here. There’s a lot of things to build. You know, until verifiable credentials are accepted everywhere, there’s going to be a bit of a chicken and egg problem. Do you have a sense or strategy on how you are tackling that problem for the initial use cases that you’re looking at verifiable credentials for, or something that you’ve seen work well?

Paul Ashley: I would say patent that we’ve seen is that there’s sort of a problem that needs to be solved, and it might even be a process problem. You have this, let’s say, these group of parties that are interacting in kind of an inefficient way. They’re either using paper to pass information among themselves, or they’ve got these interconnector API calls or something, and they know that the system’s not great. It’s inefficient. It’s costing them a lot. And so the way I look at projects at the moment is there’s a problem where you’ve got these multiple parties, and it just happens that some are issuing data and some are verifying that data, and some of them. are doing both. So you look for these networks where you’ve got these parties involved, and you want to solve a problem.

Paul Ashley: So let’s just go and tackle that problem and make it much faster, much easier for the user, much cheaper to run by replacing a paper-based system or an API integration problem system with a decentralized identity where issuer says, look, this is the information I want to present about the user, and this is the user wants to present this back to this other verifier, this relying party. At this stage, we’re not looking at boiling the ocean, but looking for these networks where you can solve a problem. And as I said, often it’s a process problem. If you look at what a lot of industries are spending with inefficient processes where they’ve got stacks of people trying to run these processes, we’ve got stacks of IT departments, a lot of it’s because of all trying to do all these integrations with a paper-based or API-based. And there really is a nicer solution now for that: decentralized identity.

Paul Ashley: And that’s why I think it’s the killer app, because I believe that you can make it easier for users, you can make it a lot less expensive and a lot simpler process by using credentials versus a lot of the current methods.

Riley Hughes: Well, you are speaking my language here with talking about identifying problems to solve and just going and tackling those problems. And if I had to extract some of the insights there, I’m hearing that maybe people should look for processes where there are stacks of people tasked with solving them manually with paper, or where there’s tricky API integration challenges to cover.

Paul Ashley: Correct. And it’s usually like a work of organizations that are participating in this, and you’re going like, let’s just put something new there and let’s get the benefits for doing that. That’s the thing that we’re looking at, is looking for projects where there’s perhaps a network of participants that can all benefit from it.

Riley Hughes: Yeah. So coming back high level again, the first bit of the conversation, talking about privacy and the pseudo concept with personas, how do we help users share less about themselves and have more privacy? On the other hand, the purpose of a verifiable credential is to be able to share information, prove information when you need to. So I think there’s sort of the one hand, which is sort of minimizing the data that’s shared, and on the other hand, decentralized identity allows people to actually share data in a way that they could never do it before.

Paul Ashley: I agree with you, Riley. There’s two sides to it. So one side of it is it makes the data much more trusted. So if I hand over a piece of paper or even show a plastic card, it’s not verified data. You can just make up plastic cards. And so I would say there’s one aspect of decentralized identity, people talk about trust or trusted data or verified data. What they mean is when the relying party, let’s say it’s that bar in Salt Lake City, gets a credential, let’s say issued from a DMV, they 100% know two things. They know that that data is real, they know who issued it, and they know it hasn’t been changed, and they know it hasn’t been revoked. You can do all of those things with credentials. If I get my driver’s license canceled, I can still go around and flash my driver’s license everywhere because people don’t know that it’s been canceled.

Paul Ashley: But in verifiable credentials, not only do you know that this is really Paul Ashley’s driver’s license, it hasn’t been altered, and it came from the DMV, but if DMV decides to revoke it, you go to present it and they go, Sorry, this has been revoked. I can’t use that anymore. So I think that’s the trusted side. But I think I talked briefly before the privacy side of it. I might get a credential, and it might have 20 fields in it or 40 fields. It could be my medical history as a credential. But when I present it over here, I get to decide what parts of that I’m happy to share. They can say, I want all 20 fields of your driver’s license. You say, Sorry, you can have two of them, and they have to decide whether they’re going to accept that or not. There is that fitting into the MySudo model of minimizing the amount of data that you’re transferring to some other organization. So I do think that’s a part of it. I actually think there’s a third aspect here, which is the whole decentralized concept.

Paul Ashley: Let’s say you have all those parties that I talked about in this network, and they have a centralized system where data goes in and data goes out. It’s ripe for abuse, either abusing access to that information they should have, insiders abusing it, data being stolen or something. When it’s decentralized, meaning the data stays over here, they give it to the user, and the user presents it over here and knows that’s the chain, it’s a lot less chance of abuse in that decentralized system. I think it is a much stronger system from privacy security point of view, because you just have the data where you need to, and the user might be willing to give some data to get a credential, and then they present the credential over here, and maybe it’s part of it, and they might get a credential in return and be able to present it over here. It’s a very controlled network there of information being passed versus a centralized system, because I’m seeing this in actual projects where you’re saying, Well, let’s get away from the centralized and let’s keep it as a decentralized system.

Paul Ashley: So I think there’s another aspect there that’s not so obvious, but the decentralization of data is also very good for private security.

Riley Hughes: Let me throw one more element out and get your take on it. When it’s easier for people to prove things about themselves, when it’s so much easier to prove that my name is Riley. More places will start to ask what my name is. Do you think that that is just an inevitable byproduct of digitization that will always occur? Do you think there’s some way to mitigate that downside?

Paul Ashley: There is ways to mitigate that. And so, for example, if you’re building a wallet for a user, you can put things in the wallet that say, for this site, previously they asked you for this data. Did you know that now they’re asking for this data? So they’ll have all of this data about you. It’s no different to MySudo. So it can warn you, for example, if you’re using this phone number or this Sudo at this site, and then you go and use another Sudo’s phone number. So it can tell you when you’re clashing. And this feels a little bit the same way where your wallet itself can warn you of things like that happening. So it could say to you, this site just previously asked you for these three pieces, they’ve just now asked you for this credential and these four pieces of information. Are you comfortable sharing it knowing that they’ve now got seven pieces and not just this four? So there is a role, I think, with the wallet and technology there to help the user. But I think it is a little bit about education as well. Why do people use federated single sign-on or social login?

Paul Ashley: Why are they logging with Google? Because it’s really convenient. It’s so easy that I just give away all my privacy. So you can, with tools, help the user, but you can also educate them to say, you’ve got this information on the wallet. Just because you’ve got it there doesn’t mean you need to give it away to everybody.

Riley Hughes: I think the product developers, people building these consumer products for users, have almost a bit of a duty to think through these concepts and build protections in for the users in the wallet UI, is what it sounds like you’re saying. You are coming from a space where you’ve built consumer products used by hundreds of thousands of people that they like enough to pay for, to do something that’s reasonably complex. It doesn’t seem like it is just so straightforward to create new personas and manage those across entities, but yet you’ve found a way to make that simple enough that people will do it and pay you for it and thank you for it. Obviously that’s a testament to the problem that you’re solving for them, but I think it’s probably also a testament to the way that you have brought these concepts together into product and an interface that was easy for users to use.

Riley Hughes: I’m sure that there are loads of lessons that you can take from your experience building the MySudo product over the last number of years and apply them to some of the domains here with verifiable credentials and wallets and things like that. Are there any concepts here that you think would be valuable to share? Any insights that you’ve gotten that would be, you think, valuable for other ID tech product builders to implement into the wallet interfaces that they’re developing?

Paul Ashley: One of the key things is when you get technology out to a user base, you’ve got to be testing it with them and seeing what works and what doesn’t work, and you have to be listening to them. We have support channels, and we get support requests in, and we look at what people are asking and where they have problems and all that. So there’s a lot of iteration, and you do things wrong and you throw it away and you do it again. But one of the big benefits of having a user base is that we can test technology with them. As we bring in new capabilities, let’s say we want to introduce a new version of the virtual cards, we immediately have a user base that’s testing it. We can get feedback and learn because you never get anything right the first time. It always takes iteration, and then sometimes you even throw it away and realize it wasn’t the right thing. So you have to be willing to test things, try half the audience on A and half the audience on B and see which one works better. And you need to be able to listen to the users and get that feedback.

Paul Ashley: So having apps with consumers, I think, is a really big benefit for a company because it allows you to get direct user-to-you feedback. We have a support screen here that shows all the support tickets that come in, and let’s say we do 100 support tickets a day. Boy, we learn a lot from those support tickets. And sometimes it’s really simple things like, I’m in MySudo app and I can’t copy this phone number across. It’s not working properly. And they go, Oh yeah, we did that wrong. We better fix that. And so that’s just one little example, but there’s a thousand of those little examples to try to get it right. And have you ever finished? No. Do you need great designers? Yeah, we even have great designers in Anonyome, but it’s still an iterative process to continue to learn and learn and learn because what’s obvious to you might not be obvious for an end user. So I think having that direct interface with normal users is really beneficial for us. So we get to test our technology.

Riley Hughes: Yeah, that’s really helpful. Anything else you’d add? Anything that maybe has worked particularly well that you think is relevant to the decentralized identity space that would sort of help the overall adoption of products in this category?

Paul Ashley: The most important thing is to get stuff out to a user into production, whether it’s an enterprise or whether it’s B2C type situation. We call the other one the B2B2C. You’ve got to get stuff in production because it’s the only way that you really, really learn about whether it’s right and whether it’s wrong, and it’s the way you improve your technology. As soon as you try to get something in production, you find a hundred things that you’re missing and you got wrong, and you fix those. So I would say getting software that you’re building into production with real users is so vital.

Riley Hughes: That’s great feedback. We then end up with time to go into the enterprise product line and business of Anonyome as much, although I know that that’s a significant portion of your business strategy. With all the context that we’ve laid out now for the consumer product, what should listeners understand and know about your enterprise product and any ties or threads that you want to connect across the two?

Paul Ashley: I would look at it this way. Why do we have an enterprise offering? It’s because enterprises came to us and say, We want to use some of your technology. That’s all it is. It’s very simple. And what do they mean, I want to use your technology? It means, well, we’ve got users and we’ve got apps, but we’d really love to provide some of those capabilities into our apps. So look at it as Anonyome providing some of the capabilities you see in MySudo and others to an enterprise so they can provide an app to their user. And it could be a mobile app, it could be a web app, it could be an extension, whatever it might be. I think we’ve got about 20 different services that we can use or we can let our enterprise customers use in their applications. The end user is using their applications, but they’d be really handy if they had some of those concepts in their application. Because enterprises are really interested in also helping their users with privacy and safety and security and that.

Paul Ashley: And so being able to have an existing user base with an application and some capability, that’s kind of the enterprise story in a nutshell.

Riley Hughes: Yeah, that’s interesting, and it is a bit of a testament to the consumer-first strategy leading to enterprise business there as well, which I think is maybe a whole topic that would be interesting to explore maybe someday as well.

Paul Ashley: I’ve got to admit, I wouldn’t want to do the enterprise business without having the consumer because as I said, when you’ve got direct consumers, you get that really direct feedback. When you’re in an enterprise solution, you’re at arm’s length to them. I think having the direct consumer applications is a way of getting a lot of really useful feedback that helps on the enterprise situation, if that makes sense.

Riley Hughes: Yeah, makes a lot of sense. Well, I always like to wrap up with this question. So, Paul, tell me what the future of identity looks like to you, and why does that matter for the world?

Paul Ashley: Where we would like it to be is we’ve got to put the user back in control. We’ve got to swing the pendulum back, and that’s not going to be easy because you have these trillion-dollar companies that really don’t want that to happen. Let’s face it, if you look at the Metas and the Googles and a whole lot of other big companies, their primary model is advertising based on knowing 99% of your life and what you’re doing, and it’s that last 1% they probably find the most difficult. But they’ll get there by providing you another app that’s free. The future is enterprises are going back to respecting user data, and what I mean respecting is not just gobbling up as much as they can, only holding what they absolutely need for their business case, and looking at more than that as a deficiency. And so I think the next 10 years, we’re going to pull one way, they’re going to pull the other way, but hopefully at the end of those 10 years it ends up where the user is back in control. Their personal data is their property. It’s valuable. Enterprises respect it.

Paul Ashley: And a lot of those big data-broking companies have just faded away. That’s, I think, the future that we all want.

Riley Hughes: That’s a great future that I want to live in. Well, Paul, do you have anything to plug? If people want to download the MySudo app and start using it in their everyday life, where should they go? If they’re interested in getting in touch with you or talking more about what you’re building, what would you suggest?

Paul Ashley: So to get the MySudo app, it’s very simple. On the App Store, it’s on the Play Store for Android. It’s easy just to download it, start playing with it, and try some use cases. I think that’s the best thing that I would suggest is think of a use case. From now on, when I talk to my electrician, I’m going to give him this phone number instead. Whatever that use case is, just try it and learn, and then see you get some value out of it. So I think that’s the MySudo case. For the enterprise case, I would say just come into our website. We’ve got lots of contact information about how we deal with enterprises and, you know, we’re always happy to work with people and just solve problems. You can do that just through our Anonyome website, and we’re easy to get in contact with.

Riley Hughes: That is great. Well, thanks for listening. You can find us on YouTube, Apple, Spotify, and wherever else you listen to podcasts. Feel free to reach out on Twitter to me at Riley P Hughes or to Trinsic at Trinsic underscore ID. And visit Trinsic if you’re interested in building the ID tech products of the future. Subscribe to get new episodes as they drop. Have a great day.