Decentralized Identity: Part One -- Trust

Last month, Nick Kramer and I moderated a discussion on Decentralized Identity at the WAGMAS Web3 Summit.  To prepare for this discussion, we interviewed four leading experts: Drummond Reed, Torsten Lodderstedt, Alan Horvat, and Manu Sporny. I also had the fortune of attending the Internet Identity Workshop at the end of April, at which decentralized identity was the hot topic

This blog series on Decentralized Identity will attempt to provide a hype-free summary of where we are–both the opportunities and the challenges in front of us.

Before we dive into the weeds, let’s distinguish between “foundational” and “contextual” identities.  A foundational identity credential uniquely identifies a natural person; its issuance is regulated by an authoritative body of a government. An example of foundational identity credentials are birth certificates, passports or drivers’ licenses. A contextual identity credential is used for a specific purpose and may or may not be tied to a foundational identity. Examples include social media accounts, bank accounts, telephone numbers, email addresses, and online profiles. 

Today, many websites and mobile applications rely on contextual identity. If a foundational identity is needed by a website (for example, if you open an online crypto currency custodial account), you may have to upload a picture of your foundational identity documents–a process we call eKYC (electronic “Know Your Customer”).  With the advent of decentralized identity, this will no longer be necessary–people will have a way to directly present a digital version of their foundational identity.  That’s a big deal.

But in order to present your foundational identity credential, you need to hold it.  This is where digital wallets come in.  Most digital wallets today are associated with holding crypto currency assets. But the technology to hold decentralized identity credentials is similar–it involves holding (and protecting) a private key which is used to provide a kind of digital chain of custody. 

Much of the excitement around decentralized identity is our desire to shed our reliance on the world’s tech juggernauts–especially Facebook, Apple, Google, and Microsoft. These hegemonic Internet giants control over 80% of social login today. Your fear of being “de-platformed” is real–especially considering the contracts of adhesion which give cloud providers the right to do whatever they want–and you little to no recourse.  Decentralized identity technology gives you the ability to “hold your own identity” –in your wallet. No one can delete it (i.e. de-platform you) or sell the data behind your back. 

But using a wallet to present an identity credential to a website is fundamentally different from how federated identity works today (i.e. social login). Consider the following diagram of how traditional federated identity works today:

Notice that in federated identity, the website consumes an identity assertion directly from the Identity Provider. The browser is used to interact with the person, but in a typical federated identity protocol like OpenID, we don’t trust the browser. The only thing that flows through the browser is a reference identifier (i.e. the code). The trust in federated identity topology is derived from the signature of the assertion from the IDP (i.e. the signed JWT), which is sent over the “backchannel”–in a TLS-secured Internet connection directly from the IDP to the website.  Let’s consider how the wallet makes this more complicated (diagram from Avast):

The credential with the green checkmark is the equivalent of the federated identity assertion. It’s still signed by the Issuer. However, it is not sent from the Issuer directly to the Verifier (i.e. website)–it’s sent from the Holder’s wallet. But how do we know that the issuer actually issued this credential to the Holder’s wallet? In order for the website to trust the credential, it must know both that the credential is valid (by verifying the signature), and that the credential was issued to this specific wallet. Furthermore, the issuer must trust the wallet to protect the credential. 


This is not some esoteric consideration. A good example of a decentralized credential is a mobile driver’s license. Apple has recently announced that eight states have signed up to adopt mobile drivers licenses and state IDs in Apple Wallet.  And the TSA has announced it will allow people to present these credentials at the airport. You can’t use Metamask or some other wallet to hold or present your state issued license. The states trust Apple to protect the credential.  Practical concerns are already thwarting our desire to liberate ourselves from GAFM.


Proponents of decentralized identity admit that new trust models are needed. While that’s true, if the past is a good indicator of things to come, we may be in trouble. It’s been hard to create trust models with federated identity–which is less complex. And even if we assume these trust models will evolve, how long will it take? One-off trust models–like the TSA trusting Arizona license issued to Apple wallets–won’t scale down to smaller Issuers and Verifiers.  But even if Issuers and Verifiers want more efficiency and inclusion, who will operate multi-lateral identity federations to lower the cost of trust?


To summarize with some bullet points (for those who don’t like to read lots of words):

In the next parts of this series, we will look at other aspects of the new decentralized identity ecosystem that is evolving, including the diversity of wallets, credentials, decentralized identifier resolution methods, and private key management.