The Killer Credential - Spotting Verifiable Credentials That Are Absolute Must-Haves for Every Party in an Ecosystem

All right, well I'm here today to talk about the killer credential. The phrase killer app has gotten so popular in the last 25 years that you can find a definition for it in the Investopedia, what is it? It's a feature or piece of software that's so good that it drives sales and growth. Killer apps can be a major source of competitive advantage, brand loyalty and profitability. In the modern economy, killer apps are sought by all kinds of businesses across many industries. I suggest that if we want to start the adoption flywheel of decentralized identity, we need a killer credential.

A lot of folks are obviously working hard on this right now, but it, it doesn't work quite the same way as your ordinary killer app. And if using some credential actually becomes really popular, not just mandated, we won't wanna pat ourselves on the back if security, privacy and user control actually get worse. So how to figure out the right answer. By the way, I've taken the liberty of using AI generated art from the dolly service from my images. They get a little weirder as we go along.

So like waiting for a train in the nineties, I was involved in the standard generalized market language sgml, otherwise known as the predecessor to xml. We joked at the time that Sgml also stood for. Sounds good, maybe later. And so the question now before us is where are we with verifiable credentials? VCs? Does it also stand for visionary but crazy?

So the decentralized identity approach that we're all familiar with now has the potential to improve both the experience and the security of onboarding, registration, authentication and consent all while increasing the quality of the personal data shared. So that could be very powerful if it takes off. And then if it's done correctly, how could it unfold? Here's my point of view. We're gonna see new ecosystems building on the last 20 plus years of technology success along with these new approaches.

That means things will be more incremental than I think some would like, but since no deployed technology ever goes away, thank Cobalt or SAML for that matter, these bridges will be essential to achieving adoption. And I envision end users negotiating new relationships with their service providers. If we find the killer credential, it will lead to a revolution of rising expectations, so to speak. People will expect greater choice in data sharing and they will be more fickle in their service loyalties and affections.

So in an environment where regulations are focusing more on user control, where the cookie apocalypse is forcing kind of an ad tech retooling and where multi identity relationships are coming into their own services that become the source of reusable credentials that actually benefit the user will gain the most loyalty. However, designing ecosystems is a risky endeavor. What is different about this whole world versus an ordinary killer app? Ecosystems are complicated and it's hard to push off an old equilibrium in order to reach a new one.

So as someone who has spent nearly a lifetime working on protocols, I have to be honest about how difficult it is to succeed with them. Every once in a while a new one sticks well enough and, and here you see moxie Marlin spike of Twitter and Signal app fame. He wrote about protocols and how they move much more slowly than platforms. The main value interoperability imposes a cost in agility. So the value has to be really, really high and it has to be high enough for everyone on all sides of the equation cuz everyone has to do something to change.

It's essentially a multi-sided market that needs to almost spontaneously erupt rather than be controlled by one company. A famous example is Uber with a multi-sided market. Note that when Moxie says decentralized here, that would include federation as well as we know it regarding his last suggestion here at the bottom about taking a protocol stuck in time, centralizing it and iterating quickly. The biggest threat to the many new peer-to-peer protocols being advocated now is the proprietary alternatives available in device level wallets. So I wanna sort of take a trip down memory lane.

It's useful to look at the history of some of our best known and most successful protocols in our industry. For a long time we didn't have a good reliable way to do cross domain, single sign-on then came saml. I know many of you were there at the time and it was by no means guaranteed to succeed. So I for one thought that once we published SAML V1 in 2001, everyone would just go out and you know, do the necessary thing. Silly meat. It took about five years to really start to catch hold. Why was that?

Well, we had to take in into account that the business trust process puts deliberate blockers in place and relying parties a key constituency. Were concerned about liability, about outsourcing any of that job. What were the first successful use cases for one use inside a single company where eliminating integration costs was a big selling point and very tight stable partnerships where the business trust was already worked out. The IDP function was basically a cost center in this conception.

Similarly, you might remember, you might have been there open ID connect, had to keep going back to the drawing board when it was in the draft stages to satisfy the concerns of relying parties. That was a very smart on the part of that working group. What became interesting in this era was the advent of social sign where the power relationship between IDPs and relying parties kind of flipped, turning what was originally pretty much just a security conversation into an experience one.

So even with relatively similar protocols like these that did succeed, we can see that it's the incentives that shifted sometimes subtly to make them take off. So what we're facing here is that misaligned incentives have really impeded the user-centric aims that we've had for a really long time. All the while a lot of people have worked assiduously on various forms of user-centric identity. I won't go down that road of history here, but I will say this work was really animated by kind of a many sets of principles.

Think about the fair information practice principles, the privacy by design principles, the laws of identity and the self-sovereign identity principles, the challenges, things don't always work out as we think they might. So I wanna share with you a vision that I originally shared at what I think was the world's first formal conference on user-centric identity. It was in New Zealand in 2000, Nate. And so this shows a kind of achieving of peer-to-peer relationships and equal control by people and businesses.

And there's actually a lot of technical ways you could go about trying to solve something like this. Heck SAML came out of the gate in 2001 with a lot of attribute sharing capabilities, but I think the questions here on the right are still valid. 14 years later, can we find a model that really does measurably empower the parties in a more even-handed way? And can the solution really support new ways of interacting and of collecting, using and sharing data? I told you the illustrations would get weirder. I've been having a lot of fun with us lately.

So verifiable credentials have to really perform a complex maneuver. I was imagining a dive one of those complicated dives where you twist around and flip three times when blockchain technology was introduced to the identity conversation around 2014. It reignited existing streams of work and existing passions. How can we understand the ecosystem incentives that may drive broad acceptance and adoption of the current decentralized identity proposition and what's been holding us back?

Well first there's that tension that I already mentioned between technical trust, which we want to make automatable and scalable and business trust. There's a lot of deliberate throttling going on. Look at oof for example, where it's very easy to generate client IDs and then again, we have many frameworks to go and lock that down again like we see in all of the open banking initiatives.

Second, there's a tension between the disruption of new tech and the the hybrid enterprise. And here, I mean really more than just hybrid cloud, any enterprise that's been around even a few decades just collects all of that technology of the past. And as I said, you know, no deployed technology ever goes away.

You know, compared to several years ago when the OA stack was kind of dismissed by the newer practitioners who are advocating these newer solutions, there's now a wave of activities to bridge, to bridge the technologies, which I think will help. Third, there's the question of whether service providers have the appetite to actually outsource reusable attributes in a highly scalable way. No one has to really accept what amounts to federated attributes. The current trend in the face of the cookie apocalypse is to go back to first party data collection.

So many different service providers are now going through that work. Having done that work, will these service providers want to put in place what amounts to yet another method?

Finally, there's a very serious challenge of what I think of as insidious recentralization in claiming that a solution is decentralized. We may be mischaracterizing just how it works in practice. I can recommend to you some excellent reading on the phenomenon starting with that web three piece by Moxi that I mentioned earlier. Another is Mark Nottingham's, I E T F paper on avoiding centralization of the internet. He looks specifically at internet protocols there and he points out that all the ecosystem incentives that make operations kind of roll to the center over and over again.

And finally, I can highly recommend Molly White's article that was called Is Acceptably Non Dystopian Self-Sovereign Identity Even Possible? Yeah, that's a pretty low bar and I think we wanna succeed better than that.

Okay, so what are the makings of a killer credential? What if we take a kind of stakeholder centric view of analyzing the the incentives involved? This is only a top level analysis accounting for the key entities playing different roles. Organizations of course each have many different stakeholders who who often have conflicting objectives. CIOs versus CISOs versus compliance leads versus line of business owners versus marketing leads and so on. So what would a killer credential look like for an issuer to make decentralized identity a good deal?

Either the credential is something that only that service knows and can provide an abundance for. A good return on investment or the credential is cheap enough to give away, thereby maybe attracting more users to that service. That's what low friction high margin means in this case. What about a verifier? These are our punitive relying parties. Low friction and high margin for them means the killer credential needs to be a lot cheaper and easier to outsource than to collect as a first party.

In the Siam world, I'm given to understand that since a new customer can be worth tens of thousands of dollars, even expensive identity verification is worth it. So verifying a credential is a new method that might be seen as a risk of losing that customer, at least for now. But if the total experience actually lowers conversion friction right from any kind of registration time or any kind of app download time, there will surely be takers. What about a holder for the killer credential situation? These are gonna be human beings.

They need to find value in getting and using a credential, particularly reusing it in many places. And the startup costs have to be absolutely minimal. If we're talking about popularity and not just something they have a mandate to do, forcing someone to download an app just to complete a boring task that they only have to do once or infrequently doesn't count, that's not a good deal. What about wallets themselves? The killer credential will smoothly and intuitively transfer across context.

That means a wallet has to understand enough about our killer credential semantics to offer the right experiences. Finally, what about the underlying infrastructure?

And, and you all who are experienced in these protocols know there's a lot here. It had better integrate with today's backend systems. And if our killer credential really spurs network effects, every stack everywhere has to be motivated to handle it. A last thought on this, even if we hit the jackpot with the killer credential, it doesn't mean security, privacy and user control will really get better in a meaningful sense. Some things that go viral aren't very good for us. And here I'm talking about ad tech.

All right, so I wanna share with you four candidate killer credentials. Let's take a look at what seemed to be the top candidates. Do they have what it takes? First we have not a bob or what I sometimes call private PU proof of humanity. We've got at least one issuer offering something like this today in the proprietary space that's Apple with its private access token. So it's pretty cheap to provide. And bot fraud is a huge problem for every service. Getting a continuous signal that the same actual human is still there is really valuable.

The only problem here is business models that rely so heavily on advertising that they may be tempted to pump up user numbers artificially and they wouldn't be interested in this. Real human users actually benefit from knowing they're interacting with other humans. And if this one credential is established at the start of using a service without using cap and maintain smoothly in the ux, I think it's even more valuable. So I rate not a bot pretty highly. What about citizenship? All the cross-border and cross-boundary use cases that we've been seeing?

Well, governments specialize in being the issuer here and a sole issuer has powerful reasons to do so since it's their job. Government services tend to be on the receiving end here too. And if the friction of deployment can be lowered, they seem to be interested in in, in doing so. So however, it's a pretty specialized use case because of these factors. This will only be a killer credential for users if the creepy downsides of all the soul issuers and all the mandates for usage don't cancel out a magically better experience as they move across borders.

Third, the third candidate is age, age assurance. Age verification in answering are you old enough types of questions? Maybe sometimes. Are you young enough types of questions. This use case actually goes back to info card and pulling a driver's license out of your physical wallet to get into the bar.

In fact, this use case is definitely old enough to drink. In the interim though, in all that time what we've seen is that many digital scenarios for age restricted purchases and age restricted interactions have arisen. So that makes it interesting. Issuance here is also in the gov governmental realm, but there are new age estimation technologies akin to facial recognition that are probably a lot less creepy. And right now they're just relying on kind of good old web 2.0 technology.

New mandates are though making it more important to do this correctly on the verifier side, but I think people don't really find this a benefit. Rather they see it as an annoying requirement just as they do now. And this will be a prime place that we're gonna see first party fraud that will test our infrastructure around credentials. So this one is kind of middling value because it's controversial in a sense across all the different stakeholders.

Finally, there's work eligibility enabling things like remote onboarding, which got a lot more necessary in the covid era. Verifiers may be highly interested in this gig economy participants, those are our humans may make the ideal credential holders.

However, the infrastructure required will be a barrier for some time to come on both the verifier and the issuer sides. At least companies such as prior employers don't tend to have a business model around confirming that someone used to work for them. So if the friction becomes low enough for them to put things like confirming somebody used to work for them, putting, putting that into place, then they have no business model barrier to doing so. It's it's knowledge they're happy to share.

And we already have an existence proof of credentials in a very web 2.0 sense from systems like Credly that will badge people for having completed training. So I rate this one kind of middling to high. So this is how I would assess the quality of these as potential killer credentials.

Okay, so given all of this context, here are my final thoughts on what enterprises need to do. No matter where in an ecosystem for this, that they sit just for the mandates alone, they need to get serious in responding to these changes and they need to prepare now for the the experiences that users will expect in the, you know, near to Midling future. And some of this will be a change around new tech, but a lot of it has to do with integrating with the backend. Now so far I'd say what I show here is kind of motherhood and apple pie.

Things that we already probably recognize pretty well we should be alerted to. But I think there's tougher things that enterprises really need to achieve. For example, if we want to achieve our security privacy and user control aims, all of the technology that we have now, which is not going away, it tends to be used in a degraded sense in that we have a lot of attributes flowing in access tokens. So that relying parties then make decisions with that data and it puts a lot of that personal data at risk.

If we're going to be putting a lot of this new infrastructure in place, it's to eliminate the need for that. So current technology can absolutely eliminate p I I and tokens. We just have to decide to do it. Another thing we also have to do is start thinking about the replacements for the current ad tech regime, which has stimulated so much kind of bad behavior on the part of all of these different stakeholders.

And as we see the ad tech regime weakening in the face of third party cookies, at least their future being uncertain if they're not dying just yet, we have an opportunity to build new solutions for those marketers who really care. We also have to take the revocation infrastructure really seriously. I will be very sad if what we find is that there are many more copies of personal data lying around sourced from credentials rather than fewer copies as we wish that to be the case. And finally, I do think we need to be flexible about what wallets we're all gonna have to interact with.

Even those of us who have our own wallet, I don't think that device level wallets are going to be the end of the story. And I'll tell you why. The intersection of payment imperatives with identity imperatives make it attractive for service providers to provide wallet functionality and build it into every app they have. That will require a lot more thinking about that interoperability of all the semantics that I talked about. So with that, I want to include, I want to wish you all a very merry Christmas and happy holidays and a good new year. Thank you.