Following the Cambridge Analytics election scandal, the meme #DeleteFacebook is widely circulating, leading to the next question, “what is the alternative?”
The answer isn’t a “new, better” platform – it’s an open standards-based infrastructure that centers on people and enables a whole new ecosystem to flourish.
Self-sovereign identity puts people in charge their own digital identities. It means that individuals have choice and sovereignty over their digital selves to the same degree we have control over our physical selves. This aligns with the fact that we all have inherent dignity that does not come from being born in a certain place or with certain attributes other than being human.
With self-sovereign identity, individuals don’t rely on another party, such as Facebook, to issue them an identifier for their use. They create the identifiers and own and control them along with what information is shared with whom under what conditions.
Under the status quo, where we don’t own and control our own identifiers, we are subject to the the terms of another party, whether this is a corporation (Google, Facebook, LinkedIn, Twitter etc) or a government. These actors have a role to play in the identity ecosystem, but the new self-sovereign identity tools will shift the power balance.
The large organizations will be in service to, and in a relationship with, the individual rather than the individual being subject to them.
Figuring out how individuals can collect, store, manage and present their own identity information and personal data via their own devices, and with services they control, is a challenge I have been working on my entire professional career. Below I explain the key technical breakthroughs that, when combined, make self-sovereign identity possible today in a way that was not possible five years ago.
Up until now, the only way to anchor identifiers for yourself on the internet was to do so within a hierarchical name space.
For example, in a private name space, you are under a company’s terms of service. It can terminate your digital identity at any time for any reason and you have virtually no legal recourse.
Such is the case for Google email addresses, Twitter handles, Facebook accounts, LinkedIn profiles, Instagram accounts, and pretty much any site where you create a username and password that then lives under the other party’s name space and control.
Then there are globally hierarchical namespaces. There are many of these; two common ones are IP addresses managed by the Internet Assigned Numbers Authority (IANA) and the domain name system managed by the Internet Corporation for Assigned Names and Numbers (ICANN). These work together to give you the website addressing system.
You can buy a domain name from a company like GoDaddy and pay $10 to $15 a year to have a name in that namespace you “own” within the global DNS name system. In the global phone number system, you can get a number from your phone company.
In both cases, you rent your identifier. Don’t pay your bill for 30 days, or fail to renew your domain name next year, and the number will be given to, or the domain name can be bought by, someone else.
An alternative is to build a global name space just for people. This seemed like a reasonable path more than a decade ago but it never took off.
A company originally called OneName tried to do this. It changed its name Cordance and tried to launch iNames in partnership with Neustar in 2006. The company rebranded their product again as CloudNames in 2013. (For CoinDesk readers experiencing deja vu: the OneName handle had a second life as the original name for Blockstack.)
Today, however, have the possibility of real self-sovereign identity rooted in identifiers not under the control of another entity but truly controlled by the individual.
The first challenge is to make such identifiers globally unique, globally resolvable and recognizable.
The Decentralized Identifiers specification, developed under the auspices of the World Wide Web Consortium (W3C), is the basis of the solution. It outlines the format for the identifiers along with that of DID descriptor objects (DDOs), the documents containing all the metadata needed to prove control and ownership of an identifier.
This gets a bit nerdy, so bear with me. The DDO includes:
- DID (self-describing)
- List of public keys (for the owner)
- List of controlling DIDs (for key recovery)
- List of service endpoints (for interaction). This is the heart of how one builds new tools and services around the individual and puts personally identifiable information (PII) under their control.
- Timestamps (for audit history)
- Digital signature with the private key (this ensures integrity)
There are several varieties of DID and different methods but they all follow this same basic outline.
So we now that have a way to create globally unique identifiers, where are they stored? And how do people access them?
Shared ledgers (better known as distributed ledgers or blockchains) are the innovation that has made this possible.
These are networks of computers that keep in sync with each other, maintaining one global ledger or database that is mirrored and replicated across thousands of machines. Entries in the database are periodically (every one to ten minutes, depending on the particulars) cryptographically “sealed” so that they are practically impossible to change.
So when you create a DID and store it in a shared ledger, it can’t, for all intents and purposes, be erased. It can only be updated by you or your agents.
Now we have a globally resolvable yet distributed namespace. Next we need to add security in the form of cryptographic keys.
Public and private keys
How do you prove that you own a particular DID? Good old public key infrastructure (PKI).
For the uninitiated: Public and private keys are mathematically related but different numbers. Public keys can be revealed to the world, while private keys should be kept secret so only the keyholder can see and use it.
Say I want to send you a message so only you can open it. I take your public key (which has a special mathematical relationship to your private key), my public key and my private key and I use those three numbers to scramble the message. Then I send the scrambled blob over to you.
You then take my public key, your public key and your private key and use all three of those numbers to unscramble the message. This is the basis of creating secure communication channels for everything.
The shared ledger infrastructure for DIDs and DDOs allows for finding public keys which need to be findable.
So now we’ve figured out how to have globally unique, user-owned digital identifiers at scale with the ability to control and secure them. But can we have unique identifiers for each of our relationships with different entities?
In today’s broken identity system, the use of the same number across many locations links all of your activities together.
These globally unique “use it everywhere identifiers” issued by governments – e.g. Social Security numbers in the U.S. or Aadhaar numbers in India – have created massive vulnerabilities and privacy issues.
Just knowing information about a person allows you to take action “as” that person. Gathering sufficient information to do this is almost trivial. Names and dates of birth are publicly available, while Social Security numbers are widely shared, both legitimately and on the black market, where hackers auction the spoils of data breaches.
But now, using the DID infrastructure, individuals and institutions can create globally unique and single-use identifiers that, through PKI, allow for secure communication channels between the individual and the institution.
So if, say, your bank’s database is compromised and your private key there is exposed, then only that one account is affected. The private key is useless anywhere else – unlike a Social Security number today. The institution can also establish new public and private keys and a new secure connection with you.
This technology does not stop data breaches but it does reduce the impact because each relationship has its own unique identifiers rather than one identifier used across multiple contexts.
Now we’ve got the underlying infrastructure which the user does not touch. Next, we need services.
Mobile apps and cloud services
In our new system, each individual has hundreds if not thousands of unique identifiers for many different relationships with people, applications and service providers. Sounds like a nightmare to keep track of, but fortunately software can work on the end-user’s behalf to manage all these keys.
There will be companies that provide the applications and cloud services for this. However, the power will be in the hands of the individual to change between various service providers.
Additionally, people can still delegate data management to trusted agents – it could be a teenager’s parents, an elderly person’s adult children, or someone’s attorney or accountant.
The ultimate control is with the individual (or the individual’s agent), who always has the ability to change providers of this service just like we always have the ability to withdraw our money from one bank and use a different bank to store our savings.
In this setup, we give people the power to manage lots of relationships in a very secure manner.
So with all these distributed and decentralized identifiers, how do we know about key information that is relevant to particular transactions and comes from other parties?
Entities that have authoritative knowledge of a claim about you can issue a verifiable claim and record they have done so in a distributed ledger. One example of a verifiable claim is date of birth – that is a fact that your parents register with the government, perhaps before you even come home from the hospital. The county or state where you are born has a register of all births and issues birth certificates based on the claims in that registry or ledger.
It is possible for the state to zap a digital claim (the equivalent of the information on a birth certificate) to someone’s mobile app. That person can then go on to use the claim in other contexts with entities that ask for a date of birth.
Other verified claims could include a license to drive, an educational credential like a degree or something super-specific like passing one particular class, or proof you are an employee at a particular company. The standards for how to do this are moving through the W3C in the Verifiable Claims Working Group and the Credentials Community Group.
Now you can have both distributed decentralized identifiers and provability of key assertions, claims or attributes.
The ‘phone home’ problem
In the past, any solution to the verifiable claim problem involved the verifier checking in with the issuer about whether it actually issued said claim. This is known as the “phone home” problem.
To put this in concrete terms: you want to get a drink at a bar. In today’s world, the bartender looks at your driver’s license and generally believes the date of birth (unless it’s an obvious fake). But if it were a digital license, how can he “believe” it? He’d have to “phone home” to the state to check if the digital assertion that you are over 21 is true.
This is not something you want to have happen – because then the state would know all the places you used your digital verified claim. In other words, Big Brother knows where you are drinking and when.
But suppose instead that proof of claim issuance by the issuer is stored in a distributed public ledger that is discoverable by the verifier. Thus the verifier can establish the veracity of the claim and that it came from the issuer, without actually interacting with said issuer.
Just when you think that must be it, there is more. We now need to prove a claim without revealing a secret.
How do you prove a claim is true and not share all the information in it?
Returning to the bar example, how do you prove you are over the age of 21 and therefore allowed to buy alcohol but not give away your complete birthdate (or, for that matter, your name and address, which are also displayed on a physical photo ID)?
Fancy math makes cryptographic proofs really quite easy. When a zero-knowledge proof (ZKP) claim is issued to the individual claimant, he or she can re-present the claim to the verifier, who can believe it because of how it was cryptographically encoded.
You can use verified claims to share some, but not all, aspects of a claim from an issuer. This preserves privacy for the individual because not all information is shared with the verifier, who can still trust the claim’s veracity.
Not all proofs last forever, though. There are special cases and we need the power to revoke claims.
Zero knowledge proofs have been around for awhile and they work really well for the type of claim that can’t be revoked like one’s birth date (the state doesn’t come back and say “you were not born”).
However, they don’t work well for claims that do have revocation involved. For example, you are currently an employee of a particular company, but you might not be this time next year.
This in the past has been impossible to tell from a ZKP – if one was issued there was no way to tell if it had been revoked without Phoning Home, which for whole classes of claims made it kind of useless. Because knowing if something is true now, not if it was true in the past, is a key part of the claim.
The CL Proof is an even fancier bit of math that complements the ZKP. CL gives issuers the power to revoke claims and for verifiers to see those revocations even if they are ZKPs. So now you can use ZKPs for a wider range of claims.
When brought together, all of these breakthroughs mean that a self-sovereign identity system is possible now.
It is worth noting this term is relatively new; when I began on this path 15 years ago we used to call the goal we were working toward “user-centric identity.”
This new, open-standards infrastructure lays a real foundation for a new layer of the internet that will replace Facebook. A new layer where people own and control their own identities and connect to any number of tools and services under their own terms. All of the folks thinking about backing or funding alternatives to Facebook need to build on the self-sovereign identity infrastructure.
It is gratifying to see the community of individuals who have been steadfastly gathering twice a year for over 13 years at the Internet Identity Workshop succeed in making this vision a reality.