Introduction
Think of all the internet applications you use. You might use several messaging apps like Telegram and Discord, several work apps like Notion and Google Docs, several social apps like Twitter and Instagram, and several media apps like YouTube and Netflix.
And you have a separate identity for each of these applications. You must sign-in to each in order to access your profile and application data like message history, work documents, social connections, and video recommendations based on your viewing history.
We have become used to this notion of fragmented identity across the internet. Users manage many different usernames and passwords, and application data often is not shared between applications. Signing up to Twitter, Instagram, and LinkedIn requires that users build their connections up from scratch three separate times.
Companies are incentivized to not share data with other applications in order to lock users in and capture more value with proprietary datasets. Not only that but user datasets are often sold to advertisers looking for better ways to target customers with their messaging. Thus, applications are free for users on the surface, but user data and attention are mined to generate massive profits for Web2 companies. Users are forced to abide by these exploitative data sharing policies if they want to continue using the service.
Let’s start with the base case where a user is prompted to sign-in to a new app with a custom username (usually email) and password. This is the centralized identity of Web1. Sign-in credentials are specific to this one application, and user data accumulates on the application’s servers, which is not shared with third-party applications.
This still exists in some places, but most web apps have moved to federated sign-in, also known as “single-sign on” (SSO). Rather than creating a new username and password for each application, users are able to sign-in to a third-party application by reusing credentials from another application (e.g. Google account). This is an improvement on Web1 login because it reduces the number of unique usernames and passwords that users manage, but it comes at the price of privacy. SSO providers can see all the third-party services a user signs into.
Users do not control their identities in the above two examples. Their sign-in credentials and application data are stored, controlled and owned by centralized companies; therefore, companies have the ability to sell user data, censor user content, and deny service to users altogether. The fundamental problem is that a user cannot create and manage his own digital identity separate from any single application.
Web3 is ushering in a new paradigm of decentralized identity, or self-sovereign identity (SSI). In the same way that Web3 allows users to custody digital assets like cryptocurrencies and NFTs, so too will users custody their digital identities. The user will be in full control of his digital identity, allowing him to access his private data, communicate with other identities, and establish visible reputation and credibility – all without reliance on a third-party. The user will also own his application data like never before. By default, application data will be portable between dApps, and dApps will have to request data access from the user. This empowers the user with data privacy guarantees and opt-in data monetization opportunities.
Decentralized Identifiers (DIDs)
DIDs, or decentralized identifiers, are fundamental in the self-sovereign identity movement. They can be used to identify a number of different entities such as people, institutions/companies, and IoT devices. In fact, entities will likely have multiple DIDs for use in different contexts. A person might have a separate DID for personal, professional, and financial use-cases. The DID itself takes the form above.
source
And DIDs are resolved, or point to, DID Documents, which are JSON files that contain the DID’s public key, verification method, and service end-points. Users express control of their identities by creating and modifying these DID Documents. Keys that control the DID can be added or removed from the DID document, and service end-points can be modified as well.
Let’s take a step back and discuss where these keys come from. DID-enabled wallets utilize the same public-key infrastructure (PKI) that crypto wallets do. A public-private key pair is generated on a user’s device. The public key is recorded on the user’s DID Document, and the private key remains secured on the device.
This private key is what is used to prove control over the DID and the credentials associated with the DID. A user signs a message with his private key, and this signature is checked against the public key. Such cryptographic verification can be done by anyone, which frees the individual from relying on third-parties, like a certificate authority, to vouch for him.
DID Methods
DID Documents must be accessible so that third-parties can get the information needed (public key & verification method) to verify a given DID. Thus, DID Documents cannot only be stored locally. Also, DID Documents must be stored so that users can create and modify them in a permissionless and decentralized way. In other words, there needs to be a verifiable data registry for DID Documents so that verifiers can resolve DID Documents and users can perform CRUD operations on their DID Documents. This is where blockchains and decentralized storage (IPFS) come in.
The Sidetree protocol solves the problem of a verifiable data registry by storing CRUD operations on IPFS, and anchoring the IPFS commits on a blockchain. There are a variety of Sidetree implementations that anchor to different blockchains including Bitcoin (did:ion), Ethereum (did:ethr / did:elem / did:3), Kilt (did:kilt), and many more. This allows users to perform CRUD operations on DID Documents such as key rotation and service end-point modification. Just as an example, if a user loses his device, and the private key stored on it, he would want to update his DID Document with a new public key that matches the key pair on this new device.
Sidetree nodes first upload DID operations to IPFS and then anchor the IPFS CID on a blockchain. Thus, IPFS persists data and the blockchain anchors act as timestamps for DID operations. This allows Sidetree nodes to time-order operations and replay them to reconstruct the up-to-date state of a given DID Document. Also, nodes only accept DID operations from the DID owner by checking digital signatures. This is what fundamentally enables a user to “control” his identity.
DID networks inherit the trust assumptions of their underlying blockchain. Bitcoin and Ethereum are public and permissionless. ION and Ceramic are two DID networks that utilize Bitcoin and Ethereum, respectively. There are other DID networks that use public and permissioned blockchains (Sovrin and HyperLedger Indy), and private and permissioned blockchains (Corda and Hyperledger Fabric).
There are other DID methods that do not rely on Sidetree implementations to manage. Some DID methods (did:pkh and did:key) do not have mutable DID Documents, and are said to be self-referencing. Obviously these are simpler to implement, but the downside is that DID keys cannot be rotated and service end-points cannot be specified in the first place. Some other notable DID methods include did:web, did:ens, and did:nft.
DID wallets are not only responsible for generating and managing DIDs, but also for managing verifiable credentials (VCs).
Verifiable Credentials (VCs)
Aside from cash, physical wallets hold a person’s credentials like his driver’s license, library card, medical insurance, and more. And these physical credentials represent claims about the person, and what services he has access to. A valid driver’s license permits a person to legally drive, and a library card gives a person access to checkout books at a public library.
Verifiable credentials are the same in principle to physical credentials – they are claims about the holder; however, they are digital and make claims about a specific DID. VCs have several unique properties.
- VCs are issued/revoked immediately as they are digital
- VCs follow a schema that make them machine-readable, verifiable by anyone, and portable across applications
- Issuers digitally sign verifiable credentials which proves authenticity of authorship. This is what makes a VC “verifiable”. A verifier can check the issuer’s digital signature against the issuer’s public key (listed in the issuer’s DID Document).
- The signature also makes the VC tamper-proof, so any change to the VC’s content would invalidate the VC.
- Finally, VCs are privacy protecting compared to normal credentials. A VC might have multiple claims about a user (e.g. age, nationality, SSN), and the user can decide which claims to selectively disclose to a verifier, without disclosing all claims at once.
- Also, VCs and zero-knowledge proofs (ZKPs) are being integrated so that a user can prove something about himself without revealing the data that supports the proof. For example, someone can verify that I am over 21 years olds (true/false) without receiving my actual age. This reduces the amount of data given up by users to access services, and has the net effect of privacy preservation.
On a technical level, verifiable credentials are JSON files made up of:
- Metadata (Issuer DID, issuance data, expiration date, etc.)
- Claims (Subject DID + Claim 1 + Claim 2 + Claim 3 + …)
- Proofs (cryptographic signature and keys for verification)
There are three entities involved when it comes to verifiable credentials: an entity that issues VCs, an entity that verifies VCs, and the holder of a VC. At a high-level, an issuer issues a VC to a holder, and signs the VC with its private key. This signed VC is sent to the holder and stored in the holder’s DID wallet. When the time comes, the holder signs the VC, and presents it to a verifier. The verifier is able to check both the signature of the user and the signature of the issuer by resolving both of their DID Documents.
In the example above, Alice needs to prove that she has a bank account (left) with Acme Bank to access a service from some other financial institution (right). Acme Bank issues Alice’s DID a VC with two claims, Alice’s name and account number. Finally, Acme Bank signs this VC, and sends it over to Alice’s DID wallet. On top of this Alice signs the VC with her wallet and presents it to the other financial institution. The financial institution queries ION with both Acme Bank’s and Alice’s DID in order to resolve their DID Documents. Now that the financial institution knows their public keys, it can check their digital signatures and verify that the original VC was indeed issued by Acme, and presented by Alice.
Now we have a good understanding of the decentralized identity ecosystem composed of DIDs, DID Documents housed in verifiable data registries (e.g. ION), and VCs held in wallets that make claims about a given DID. Similar to how crypto wallets are the main interface for interacting with blockchain, DID wallets are the main interface for interacting with decentralized identities. Eventually, crypto wallets and DID wallets will be combined. A private key, public key, blockchain address, and DID will all be generated when onboarding to a wallet.
For now, DID wallets are a category of their own. Nomios is a good example of a DID wallet. It is a cross-method DID wallet that aggregates multiple identities into one UI. Some other wallets include SpruceID’s Credible, Dock (iOS), and Bloom (iOS).
There are also many DID clients available that allow developers to integrate VC verification, issuance, and signing into their application. Some notable DID SDKs include SpruceID’s cross-method DIDKit, Nomios’ IDM SDKs (Wallet, Client, Bridge), Bloom’s SSI SDK, and tbd’s Web3 SSI SDK/Service. Crucible’s Emergence SDK brings DID functionality to game developers so that gamers will have DIDs that control their avatars, and data like achievements and in-game items.
Soon, wallets and Web3 dApps will be equipped to handle decentralized identity with the following functionality:
- Manage identity – create identities using a preferred DID-method
- Manage verifiable credentials – view, add and remove VCs to and from a wallet
- Digital signatures – with session private key or device private key
- Verify signatures – verify an artifact signed by a session private key or device private key
- Authenticate users – a sign-in mechanism so that dApps can persist sessions and provide a custom experience to returning users (more on this below)
- Authenticate dApps – applications will pass the wallet its DID and signature, so that the wallet can verify the authenticity of the site
Emerging VC Products
Enterprises like colleges, governments, or certificate programs often need to mass issue credentials to those they serve. Many organizations today still mail physical credentials, which means issuance is not instant and fraud exists because physical credentials are subject to fraud with counterfeit documents. Issuance platforms make it so that organizations can instantly send out cryptographically secure VCs en masse. Some specific examples include Transmute’s Verifiable Data Platform, Dock’s Certs Platform, and Affinidi Console.
There also exists VC issuance as a service. Civic, Fractal, and BrightID are three such examples and issue credentials related to know-your-customer (KYC) and proof-of-personhood. Specific VC offerings include:
- Know-Your-Customer (KYC) – Connect identity documentation to DID (passports, drivers licenses, etc.)
- Liveness – Is this DID a human?
- Uniqueness – Is this DID a unique person?
- Location – Where is the user located?
- Sanction screen – Is the user a sanctioned person?
Civic offers a UI called Civic.Me where you can lookup a user’s wallet address, and see the credentials Civic has issued to that wallet. Civic is actually not DID-based, but on-chain and smart contract based. More on this later.
VCs are most applicable in the DeFi sector right now. These VCs are sent to a user’s crypto wallet, which gives access to permissioned token launchpads and exchanges that are required to KYC their users. Verite and Violet are two projects that specialize in this. Also, VCs can be used as a credit score mechanism. Tracking credit score in this way can give crypto users access to under-collateralized loans, as opposed to the capital inefficient, over-collateralized loans that currently plague DeFi (ArcX and Bloom). Also, proof-of-uniqueness, liveness, and personhood can be used to limit bots from accessing NFT mints and token airdrops.
Decentralized Web Node
Verifiable credentials are stored in a DID wallet on the user’s local device. This is okay for ad hoc verification where the user wants to provision a service and must manually present a VC to a verifier in order to do so; however, we need an easy way of discovering and interacting with other DIDs and VCs, and local storage doesn’t provide this. Also, what if we want to use a DID wallet across multiple devices so that our VCs automatically sync between a smartphone and computer, for instance? This brings us to the concept of a decentralized web node (DWN), which is the final component in the DID ecosystem.
DWNs serve as a message relay and data storage mechanism controlled by a given DID. Data related to a DID, such as VCs and application data, will be stored on the cloud. This allows the user to access his identity data from any device. All data will be private and encrypted by default, but users can choose to publicly expose VCs. Other entities can locate this public data by navigating to the user’s DWN, referenced as a service end-point in the user’s DID Document. This unlocks many P2P use-cases.
Let’s look at the most simple example of a DWN in action. Alice has the DID of a bank she is interested in using, but first wants to verify the bank’s charter. This charter is represented as a public VC exposed on the bank’s DWN. Alice finds the bank’s DWN from its DID Document, queries the endpoint for the charter VC, and verifies the charter.
DIDs and DWNs also enable P2P, encrypted messaging. A sender can encrypt a message with a recipient’s public key, and send this encrypted message to the recipient’s DWN. The recipient’s DWN could then decrypt the message using the recipient’s private key, and relay this decrypted message to the recipient on his device. The recipient would go through the same process in order to respond to the original sender.
Finally, we can imagine hosting user-controlled application data on DWNs. This enables users to store their own application data as opposed to data being locked in the application’s server. Application data is private by default on a user’s DWN, but the user can selectively give applications read/write permissions. This is a complete reimagination of current web app architecture, and is termed by tbd as “decentralized web apps”.
Data is made interoperable between applications. Music playlists, listen history, and song likes can be recorded on one application, and ported over to another application that might apply different algorithms for song recommendations. The same can be done for your connections and group memberships across multiple social media apps.
Planning trips requires multiple apps. You book your flight, hotel, car rental, and dinner reservations all on different web apps. We can give all these service providers access to our trip data so, if we change our flight date, then our travel and rental car dates can automatically update accordingly.
Finally, I would be remiss not to talk about tbd’s Web5 initiative. Tbd is a subsidiary of Twitter, and they have envisioned an entire Web5 ecosystem built around decentralized identifiers and decentralized web nodes. They are building out SSI-related SDKs, but the first major consumer product will be tbdDEX, a decentralized on-ramp into crypto.
This decentralized exchange is built on top of DIDs, VCs, ION, and DWNs. Users can buy and sell crypto to participating financial institutions (PFIs) with message exchange facilitated by DWNs. PFIs will likely require KYC VCs in order to engage with users, but this depends on jurisdictions and is not an explicit requirement made by the tbDEX protocol.
Ceramic and User-Controlled Data
Ceramic is an important project to highlight in this space. It’s an early implementation of a decentralized web node, because it facilitates DID-controlled, decentralized data storage. Ceramic is a decentralized network of data storage nodes built on top of IPFS. User-controlled data including DID Documents and application-specific data reside in Ceramic data streams, which are persisted on Ceramic nodes. Only the user who created the stream is able to write to the data in that stream, and write operations must conform to the stream’s schema, or data model.
A stream is essentially an append-only list of write commits. Ceramic anchors these commits to the Ethereum blockchain, which gives Ceramic nodes a time-ordering of the stream’s commits. This allows Ceramic nodes to individually come to consensus on the current state of a stream.
As I said before, Ceramic is all based around a user’s DID. This brings us to Ceramic’s Identity Hub, which is essentially a table of all data streams associated with a given DID. Instead of applications writing to their centralized databases, applications can instead write to a user’s Ceramic stream.
Beforehand the application developers create a schema, which is a data model for a given data set within an application. A good example of this is profile data like a user’s name, profile picture, bio, and more. The schema and definition are both their own Ceramic streams, and are thus mutable. And users fill in their data, which creates a Ceramic stream on the backend that conforms to this specific schema.
Self.ID, disco.xyz, and dns.xyz are all implementations that use Ceramic on the backend. Orbis offers developers an SDK for integrating Ceramic-powered social media (graph, posts, comments, messaging) into their applications. This brings user-controlled social media to Web3 dApps. Other Ceramic projects include Ceramic Network explorers, reputation apps (e.g. Gitcoin Passport), user-generated content apps (social, blogs, messaging), and dynamic NFTs.
Ceramic is not the only player in the user-controlled data category. Fleek’s Space Daemon, which utilizes ThreadsDB, allows developers to integrate user-controlled storage capabilities into their dApps. Such storage capabilities revolve around the idea of client-side encryption, which necessitates that users encrypt their data with their public keys before storing it on IPFS. Contrast this to the current model of server-side encryption, where a central company holds the private keys, and can decrypt user application data whenever needed. Other user-controlled storage projects include Skynet’s SkyDB, SpruceID’s Kepler, Verida, and Privy.
dApp Authentication: Passwordless-Login and dApp Sessions
Web2 Sign-In
Web apps must confirm that we are the person we say we are (authentication) so that it can give us read/write access to our application data (i.e. authorization).
There are two popular sign-in methods on the web today: custom usernames and passwords for each web app (centralized), or single-sign-on (federated). Starting with centralized login, each application stores a table of a username and password (actually a hashed password). When the user enters his credentials the web app checks the password in this lookup table in order to authenticate the user. This is a nuisance because the user must manage many different usernames and passwords.
Federated sign-in allows us to reuse credentials across multiple applications. There are several common identity providers like Google and Facebook that provide authentication services for logging into third-party applications. This is an improvement over centralized login, because federated login likely reduces the number of credentials a user must manage; however, it comes at the cost of privacy because the identity provider can track all the third-party applications the user signs into.
Open ID Connect (OIDC) and OAuth, provide the authentication and authorization protocols, respectively, that power single-sign-on. When a user clicks “Sign in with Google”, he is redirected to Google’s authentication server where he then enters his Google credentials. Google’s authentication server then sends an access token to the third-party app’s server. This access token has scoped credentials like what Google data the third-party app is authorized to access, and for how long (i.e. expiration). For example, an online photo editing software may request access to a user’s Google photos.
Web2 Sessions
Web app servers need a way to persist state across multiple screens. If I sign-in and navigate to another application tab, I still expect to be signed in once I land on that new tab. Once the user signs in, the server stores information about that user’s session. The user’s session is referenced by a sessionID, which exists on the server but is also sent to the user as an HTTP cookie. This sessionID is stored locally on the user’s browser.
The browser includes this cookie in every subsequent request it sends to the server. This automatically re-authenticates the user and prevents the user from having to reenter credentials for every action he takes. The cookie, like the authentication access token described in the section above, expires or is deleted after closing the browser. This means that sessions are temporary. For example, banks automatically sign me out of my mobile app after 15 minutes for security reasons.
Web3 Sign-In
At this time, most dApps do not support sign-in and web sessions. Users connect wallets and use their private key for signing on-chain transactions, but this doesn’t support the web sessions we are accustomed to. There are a few dApps that have implemented sign-in for improved UX. For example, OpenSea and Mirror authenticate users with message signing in order to load user metadata like profile information and preferences like light/dark mode.
Initiatives are underway to push Web3 sign-in forward. EIP-4361 standardizes the sign-in message format so that wallets can provide users with friendlier signing experiences that more clearly communicate to the user what permissions are being given to the dApp.
Also, Web3 sign-in is being integrated into OAuth infrastructure so users can now sign into Web2 applications using their Web3 wallet. Sign-In With Ethereum (SIWE) is the most well-known initiative in this space. SpruceID led an initiative to deploy a Cloudflare-hosted identity provider at https://oidc.login.xyz/, which has been integrated into OAuth and SSO. Docks Web3ID works in much the same way.
SpruceID plans to extend Sign-In With Ethereum functionality by adding dApp sessions so users don’t have to sign a message every time they want to perform an off-chain action. An ephemeral key will be generated on the backend and the user will delegate down-scoped permissions to this ephemeral key by signing a message.
Decentralized Key Management as Authentication
DID and crypto wallets are challenging from a user onboarding perspective, because users are responsible for backing up and managing their private keys. Decentralized key management (DKMS) comes in to save the day.
Magic.Link and Web3Auth are non-custodial Web3 wallets that do not require the user writing down their seed phrase. The two products have different architectures but both allow users to seamlessly create a wallet by signing in with OAuth/SSO, or entering in their email. A private key is created for them on the backend, and securely managed in a non-custodial way, either in an AWS HMS instance (Magic.Link) or in a threshold cryptography network (Web3Auth).
When a user wants to access his crypto wallet, he uses Web2 SSO and his private key is fetched or reconstructed on the backend. This improves Web3 UX because users can continue signing in with familiar Web2 SSO in order to access their wallet, and initiate dApp sessions.
On-Chain Identity
Soulbound Tokens
The DIDs and VCs we’ve talked about are considered off-chain identity, because they do not exist on the blockchain. DID Document operations are anchored on Layer 1 blockchains, per Sidetree protocol implementations, but this is besides the point. There is another school of thought that decentralized identity should exist on-chain.
Some have suggested identity-style NFTs called Soulbound Tokens (EIP-5114) that are non-transferrable. They could be used to represent things like identity, attendance, and potentially governance rights. Non-transferability is essential because it defeats the purpose of identity if users can simply transfer credentials, like participation in a protocol’s governance or in-game achievements.
Some smart contract standards have emerged that support identity use-cases like ERC-725 that represents DIDs, and ERC-735 used for adding or revoking VCs from DIDs. It should be noted that there are pros and cons to off-chain versus on-chain identity. Credentials are thought to be more available with on-chain identity, and easier to compose in smart contracts; but, also there’s a cost in creating and updating DIDs/VCs with on-chain transactions, and privacy concerns abound.
Blockchain Naming Services
Blockchain naming services represent another category related to decentralized identity. Ethereum Naming Service (ENS), Handshake (HNS), and others seek to provide decentralized alternatives to the Domain Naming Service (DNS) that is centrally managed by an organization called ICANN.
ENS is by far the most popular. It essentially maps a user’s machine readable Ethereum address (e.g. 0xb50065FE8a921ab97F97cb580029efAc183f1209) to a human-readable username like travis.eth. This is similar to how DNS resolves human readable domain names (google.com) to machine-readable IP addresses (2001:4860:4860::8888); although, ENS is managed by a series of smart contracts, whereas DNS is managed by a central organization, and domains are registered on DNS servers by central registrars (e.g. GoDaddy).
Users pay for a yearly subscription to maintain control of their ENS subdomain, and also have the ability to fill out a text record, so that ENS can resolve other metadata like IPFS hashes for profile pictures, or static websites. Handshake is an entire blockchain in itself that is trying to replace DNS root servers, and control all top-level domains (TLDs) like com, edu, org, and io. It’s architecture is very similar to Bitcoin’s UTXO model, and TLD’s are bid on and won forever, unless transferred to others.
0 Comments