This article covers the core concepts of decentralized identity, the evolution of identity on the Internet, a layer-by-layer overview of the Web3 identity infrastructure stack, and related developments in privacy primitives. Proof-of-Personhood, compliance, and application layers will be covered in future articles.

Identity is an emergent property composed of data associated with a person, entity, or object. In the physical world, we store this data in our brains in the form of abstract reputations and psychological associations. In the digital world, identity is formalized into two components:

  • Identifier: A unique set of characters or numbers that identifies a subject (e.g., passport number, Twitter ID, student ID).

  • Data related to the subject (e.g. travel history, tweets and followings, academic achievements).

Creating an identity layer for the internet is difficult because there is a lack of consensus on what it should be and how it should operate. Digital identity is tied to context, and we experience the internet through a variety of content that exists at least in many different contexts. Today, much of our digital identity is fragmented and under the control of a few stakeholders whose interests are in preventing us from spilling over from their context into anywhere else.

  • Businesses view customer relationships as a key asset and are reluctant to give up control of those relationships. Until now, there has been no incentive to do so. Even a one-time, temporary identity is better than a framework they cannot control.

  • Specific industries like finance have unique needs (such as compliance) when it comes to maintaining digital relationships with customers and suppliers.

  • Governments have needs that are distinct from other types of organizations. For example, they have jurisdiction over driver's licenses and passports.

This model creates an asymmetry of power between individuals and the parties that manage our identities and data. It limits our autonomy, preventing us from consenting, selectively disclosing information about ourselves, and porting our identities across contexts for consistent experiences online and offline.

Decentralized identity was already a collective effort before the rise of Crypto and web3. The overall goal is to allow individuals to regain autonomy over their identity without relying on a centralized, single gatekeeper. The misuse of customer data and the erosion of trust in large companies have made decentralization central to the next era of internet identity.

1 The core concept of decentralized identity

Decentralized identifiers (DIDs) and proofs are the main building blocks of decentralized identity. DIDs are published and stored in a Verifiable Data Registry (VDR) as an autonomous "namespace" that is not centrally managed. In addition to blockchain, decentralized storage infrastructure and P2P networks can also serve as VDR.

Here, entities (individuals, communities, organizations) can use a decentralized public key infrastructure (PKI) to authenticate, prove ownership, and manage their DIDs, which, unlike traditional network PKI, does not rely on a centralized certificate authority (CA) as a root of trust.

Data about identities is written down as attestations, which are "claims" made by one identity about another (or themselves). Verification of claims is done through cryptographic signatures implemented by the PKI.

Decentralized identifiers have 4 main properties:

  • Decentralization: Creation without reliance on centralized institutions. Entities can be created however they want, keeping their desired identities, roles, and interactions separate in different contexts.

  • Persistence: Once created, it is permanently assigned to an entity. (Although some DIDs are designed for ephemeral identities).

  • Parsable: Can be used to reveal additional information about the entity.

  • Verifiable: Entities can prove ownership of a DID or claims about it (verifiable credentials) without relying on third parties, thanks to cryptographic signatures and attestations.

These properties distinguish DIDs from other identifiers such as usernames (not verifiable), passports (not decentralizable), and blockchain addresses (non-persistent, limited resolvability).

The World Wide Web Consortium (W3C) is an international community of organizations, staff, and the public working together to develop web standards. W3C's DID Spec defines 4 main parts:

  • Scenario: The prefix "did" tells other systems that it is interacting with a DID rather than another type of identifier, such as a URL, email address, or product barcode.

  • DID Method: Specifies to other systems how to interpret the identifier. There are over 100 DID methods listed on the W3C website, usually associated with its own VDR, and with different mechanisms for creating, resolving, updating, and retiring identifiers.

  • Unique Identifier: A unique identifier specific to a DID method. For example, an address on a specific blockchain.

  • DID file: The 3 sections above parse into a DID file, which contains the way the entity can authenticate itself, any properties/claims about the entity, and pointers to the location of additional data about the entity (the "service endpoint").

2 Impact of Crypto

While Public Key Infrastructure (PKI) has been around for a long time, Crypto has accelerated its adoption through the incentives of token networks. What was once used primarily by privacy-focused technologists is now a prerequisite for participating in the new economy. Users need to create wallets to self-custody their assets and interact with web3 applications. Driven by the ICO boom, the summer of DeFi, NFT mania, and the tokenized community, users have more keys in their hands than ever before. With it comes a vibrant ecosystem of products and services that make key management easier and more secure. Crypto has been the perfect Trojan Horse for decentralized identity infrastructure and adoption.

Let’s start with wallets. While wallets are still primarily thought of in the context of asset management in a financial sense, tokenization and on-chain history already allow us to represent our interests (NFT collections), work (Kudos, 101), and opinions (governance voting). Losing a private key is becoming less like losing money and more like losing a passport or social media account. Crypto blurs the line between what we own and who we are.

However, our on-chain activities and holdings give a limited view of who we are (and not privacy-preserving). Blockchain is just one layer of the decentralized identity stack. Other stacks also help solve important problems, such as:

  • How do we identify and authenticate ourselves within networks and ecosystems?

  • How do we prove our stuff (reputation, uniqueness, compliance) while maintaining privacy?

  • How do we grant, manage and revoke access to our data?

  • In a world where we control our own identity and data, how do we interact with applications?

Solutions to these problems will have a profound impact on what the Internet will look like for generations to come.

The following sections will describe the Web3 identity stack layer by layer: verifiable data registry, decentralized storage, data mutability and composability, wallets, authentication, authorization, and proof.

3 Web3 Identity Stack

Blockchain as a verifiable data registry

The distributed and immutable nature of blockchain makes it suitable as a verifiable data registry, and DID is issued on this basis. In fact, various public blockchains have W3C DID methods, such as:

  • In Ethereum, did:ethr:public key represents the identity of the Ethereum account.

  • Cosmos, did:cosmos:chainspace:namespace:unique-id represents assets that are compatible between Cosmos chains.

  • Bitcoin, where did:btcr:btcr-identifier represents a TxRef-encoded transaction ID referencing the transaction position in the UTXO-based Bitcoin blockchain.

Notable is did:pkh:address – a ledger-agnostic generative DID approach designed to enable interoperability in blockchain networks. According to the CAIP-10 standard, it is an account ID, used for cross-chain key pair expression.

Fractal is an identity provisioning and verification protocol designed for applications that require unique and varying levels of KYC for their users. After completing validity and/or KYC checks, Fractal DIDs are issued to the corresponding Ethereum addresses and added to the corresponding lists. Fractal's DID registry is a smart contract on Ethereum that allows transacting parties to query Fractal DIDs and their verification levels.

Kilt, Dock, and Sovrin are application-specific blockchains for self-sovereign identity. As of this writing, they are primarily used by enterprises to issue identities and credentials to end users. In order to participate in the network, nodes need to stake native tokens in order to process transactions such as the issuance of DID/credentials, define credential schemas, and perform revocation updates.

Decentralized data storage

While general-purpose blockchains can also serve as data sources for immutable user data such as asset ownership and transaction history (such as portfolio trackers and “DeFi Score” applications), they may not be suitable for storing most data about users because writing and regularly updating large amounts of information is operationally expensive and compromises privacy because data is visible by default.

That said, there are some application-specific blockchains, such as Arweave*, that are designed for permanent storage. Arweave pays miners block rewards and transaction fees in exchange for copies of information stored on the network. Miners need to provide "proof of access" in order to add new blocks. A portion of the fees is also paid into a permanent endowment fund that will be paid to miners in the future when storage costs cannot be covered by inflation and fees.

Ethereum and Arweave are examples of blockchain-based approaches to data persistence. On Ethereum, every full node must store the entire chain. On Arweave, all the data needed to process new blocks and new transactions is recorded in the state of each individual block, allowing new participants to join the network simply by downloading the current block from their trusted peers.

Contract-based persistence means that data cannot be permanently copied and stored by each node. Instead, data persists by signing contracts with multiple nodes, which agree to hold a piece of data for a period of time and must renew the contract whenever they run out to keep the data persistent.

IPFS allows users to store and transfer verifiable, content-addressed data in a peer-to-peer network. Users can save the data they want on their own IPFS node, utilize a dedicated node group, or use a third-party "pinnin" service such as Pinata, Infura, or web3.storage. As long as there is a node storing the data, the data will exist in the network and be available to other nodes when they request it. On top of IPFS are cryptoeconomic layers such as Filecoin and Crust Network, which aim to incentivize the storage of data for the network by creating a distributed market for long-term data persistence.

For personally identifiable information (PII), permissioned IPFS can be used to comply with the GDPR/CCPA right to be forgotten as it allows users to delete their data stored on the network. Identity wallet Nuggets takes this approach and decentralizes it further by letting merchants and partners run dedicated nodes.

Other contract-based decentralized storage solutions include Sia and Storj, which encrypt and split individual files across multiple nodes across the network. Both use erasure coding (requiring only a subset of storage nodes to serve files) to ensure data availability even if some nodes go offline. They also have a built-in incentive structure and use native tokens for storage.

Data changes and composability

General purpose blockchains, Arweave, and IPFS all guarantee immutability, which is a useful property for data such as static NFT art and permanent records. However, most of our interactions with applications today continually update our data. Web3 protocols designed for mutable data are designed to achieve this, leveraging the decentralized storage layer below.

Ceramic is a protocol for decentralized data mutability and composability that works by transforming immutable files in persistent data storage networks like IPFS or Arweave into dynamic data structures. On Ceramic, these "data streams" are like its own mutable ledger. Private data can be stored off-chain, with its schema indexed on Ceramic, attached to a DID data store leading to external private storage.

When users update their profile in a Ceramic-powered application, the protocol validates those updates as a stream, transforming it into a new state while maintaining track of previous state changes. Every update on Ceramic is authenticated by a DID that can be mapped to multiple addresses, paving the way for users to update their data without a server.

Today, Web2 entities own the UI and backend, where they store and control user data. Google and Facebook use this data to algorithmically personalize our experience on their platforms, further productizing the data they collect. New applications have to be built from scratch and cannot provide a personalized experience from the start, making the market less competitive.

Web3 democratizes data, leveling the playing field for new products and services, and creating an open environment for experimentation and a competitive market for applications. In a world where users can bring their data from one platform to another, application developers don't need to start from a blank slate, and they can instantly personalize the experience for their users. Users can log in with their wallets and authorize applications to read/write to a "database" that they fully control.

ComposeDB on Ceramic is a decentralized graph database that enables application developers to discover, create and reuse composable data models using GraphQL. Nodes in the diagram are accounts (DIDs) or files (data flows). The edges in the graph represent relationships between nodes.

A DID represents any entity that can write data to the graph, such as an end user, organization, application, or any type of authentication service.

Models are Ceramic streams that store metadata about the document's data structure, validation rules, relationships, and discovery information. Developers can create, combine, and remix models into data combinations that serve as the database for their applications. This replaces the traditional user table with a centralized UID and related data. Applications can be built on a common data set controlled by users, rather than managing their own independent tables.

Since applications can permissionlessly define the models they will use for a specific context, the curation marketplace becomes very important because it provides a signal for the most useful data models (schemas defined for social graphs, blog posts, etc.). With a marketplace for these data models, applications can signal these models, making them more easily consumable. This will incentivize public datasets to produce better analytics and infographics so that products can further innovate on top of them.

Tableland is an infrastructure for mutable, structured relational data where each table is minted as an NFT on an EVM-compatible chain. The owner of the NFT can set up access control logic for the table, allowing a third party to perform updates on the database if that party has the appropriate write permissions. Tableland runs a network of off-chain validators that manage table creation and subsequent changes.

On-chain and off-chain updates are handled by smart contracts, which point to the Tableland network using baseURI and tokenURI. With Tableland, NFT metadata can be mutated (using access control), queried (using SQL), and combined (with other tables on Tableland).

Smart contract standards like ERC-20 and ERC-721 give dapps a shared language about how we create and transfer tokens, and data model standards give dapps a shared understanding of profiles, reputations, DAO proposals, and social graphs. shared understanding. This data can be reused by multiple applications through an open registration that anyone can submit.

Decoupling applications from the data layer allows users to port their content, social graph, and reputation between platforms. Applications can access the same database and be used in its context, enabling users to have a composable reputation across different contexts.

wallet

Broadly speaking, a wallet includes interfaces and underlying infrastructure for key management, communication (data exchange between holders, issuers, and validators), and claim presentation and verification.

It is worth distinguishing between crypto wallets (MetaMask, Ledger, Coinbase Wallet, etc.) and identity wallets. Crypto wallets store cryptographic keys unique to the blockchain network and are designed to send/receive tokens and sign transactions. Identity wallets store identities and allow users to create and provide claims so they can provide identity data across applications and services.

Examples of identity wallets include ONTO, Nuggets, and Polygon ID Wallet. Some identity wallets, such as Fractal, include validity checks and KYC as part of their onboarding process, so users can have a claim to submit to applications that have such requirements. This is much less common among crypto wallets. Additionally, identity wallets are also more likely to support W3C-approved DIDs, Verifiable Credentials, and DIDComm implementations, as well as use cases outside of web3.

WalletConnect is a communication protocol that connects wallets to wallets and dapps. As a minimalistic, unbiased protocol that has already served millions of crypto users, WalletConnect may prove to be a strong alternative to DIDComm in accelerating the adoption of self-sovereign identity infrastructure. Unlike DIDComm, which requires service providers to provide managed mediator infrastructure, WalletConnect stores information in a "cloud mailbox" on the relay network and pushes this information to wallets when they are back online.

Certification

Authentication is the confirmation of a user's identity based on one or more authentication factors. An authentication factor can be something the user has (digital signature, ID card, security token), something they know (password, PIN, secret answer), or a biometric (fingerprint, voice, retina scan).

In the decentralized identity paradigm, users can authenticate themselves using their wallets. Behind the scenes, the wallet uses its stored keys to generate a digital signature that serves as "proof" that the holder owns the private key associated with the account. Since crypto wallets can generate signatures, applications that offer web3 logins are able to let users authenticate with their Metamask or WalletConnect.

For years, crypto users have interacted with dapps through connected wallets. The dapp has no memory of connected users and treats them as a blank slate every time they visit a website.

Today, users have deeper interaction patterns with dapps. This is where decentralized identity becomes useful because it allows applications to gain more context around the user, providing a personalized experience while letting individuals retain control over their own data.

For richer contextual interactions, such as loading user preferences, profiles, or private chat messages, the application needs to first ensure that it is talking to the actual key holder behind the account. While Connected Wallets don’t offer this guarantee, certification standards do. Authentication establishes a session with the user and allows applications to securely read and write their data.

Sign-In with Ethereum (SIWE) is an authentication standard pioneered by Spruce, ENS and the Ethereum Foundation. SIWE standardizes a message format (similar to jwt) for users to use a blockchain-based account login service. Sign-In with X (CAIP-122) builds on this foundation, making SIWE an Ethereum-centric implementation of SIWx, generalizing the standard to operate across blockchains.

For individuals, this means being able to register or log in with their web3 wallet, without having to create a username and password, with a “just a few clicks” user experience that mimics social logins while maintaining sovereignty over their online identity. Applications can use this as a marketing strategy to target web3-native audiences, meeting user needs.

In the medium term, the ability to log into dapps and other web2 services using a crypto wallet will become a user experience improvement native to web3. However, this will expose users to correlation and tracking issues that become very detrimental in web2. Authentication through Peer DIDs or self-certified identifiers can serve as an alternative solution.

Unlike the "normal" DIDs described above, Peer DIDs are designed to be used between 2 or N known parties. They can be used as a unique identifier for each service and/or interaction. The encrypted wallet address in this digital identity can be stored with VC as verification evidence for each merchant or service interaction.

Authorization and access control

Authentication confirms a user's identity, while authorization determines what resources an entity should be able to access and what they are allowed to do with those resources. These two processes are independent, but often go hand in hand in the user experience process. After logging in to a third-party service using social login, the user may be prompted with some authorization requests, as shown in the following figure:

In a federated identity model, you authorize third-party applications to view or update your data stored with an identity provider (like Google), who maintains a list of permissions you have granted to these applications. Web3 authorization infrastructure and standards help achieve the same goal, except you own your data self-sovereignly and can grant each third party the right to decrypt/read/update it without the need for a centralized middleman.

With the rise of tokenized communities, web3 token-gated products such as Collab.Land, Guild, and Tokenproof have emerged. A major use of these tools is access control for member-only Discord channels, with more granular access based on role and reputation. Rather than manually assigning access, communities can programmatically grant access based on token holdings, on-chain activity, or social validation.

Lit is a decentralized key management and access control protocol that leverages MPC technology to distribute "shares" of private keys among Lit network nodes. A public/private key pair is represented by a PKP (Programmable Key Pair) NFT, whose owner is the sole controller of that key pair. When arbitrarily defined conditions are met, the owner of the PKP can trigger the network to aggregate a share of the key to decrypt files or sign information on their behalf.

In the context of access control, Lit enables users to define on-chain conditions that grant access to off-chain resources. For example, a DAO could upload a file to Arweave or AWS, encrypt it with Lit, and define a set of conditions (such as NFT ownership). Qualifying wallets sign and broadcast a message to protocol nodes, which check the blockchain to ensure the signer is eligible and, if so, aggregate key shares for the signer to decrypt the file. This same infrastructure can also be used to unlock web2 experiences like Shopify discounts, locked Zoom rooms and Gathertown spaces, live streaming, and Google Drive access.

Kepler organizes data around user-controlled databases ("Orbits"), which represent a designated list of hosts for the data and, as a smart contract, only their keys can control it. These databases can be managed by trusted parties, consensus mechanisms across hosts, resource owners, and permission validity. Anyone using SIWE can immediately take advantage of a private database to store their preferences, digital certificates, and private files. With "bring your own storage" support for multiple storage backends, users can self-host or use a managed version.

Some examples of how applications can use combinations of the previously mentioned building blocks:

  • Orbis is a social network application ("web3 Twitter/Discord") that uses Ceramic for data storage and updates. Private messages are first encrypted with Lit before being stored.

  • Use Lit as a decentralized encryption system to delegate who can decrypt your Tableland data.

  • Kepler can use Ceramic documents as a beacon to route to private stores.

  • Creating Lit PKPs lets applications "own" a Ceramic stream and grants Lit Actions (code on IPFS) the ability to sign and update the database if arbitrary conditions are met.

CACAO is a standard for expressing chain-agnostic object capabilities (OCAP), created using Sign-in-With X. It defines a method to record the results of SIWx signature operations as IPLD-based Object Capabilities (OCAP), creating not only authenticated event acceptances, but also composable and replayable authorization receipts for verifiable authorizations.

The authorization method lets users grant applications fine-grained, well-scoped and verifiable ability to view/update their data. Additionally, it can be session-based so that they don't have to sign a message on every update, but rather have a rich interaction on the application and sign once at the end of the session.

Certificates and Credentials

Here we reach the top of the decentralized identity infrastructure stack, as shown in the figure.

Some terms:

  • Attestation refers to the attestation that a statement and signature are valid and arises from the need for independent verification of recorded events.

  • A voucher is any document detailing information about one entity, written and signed by another entity or themselves. Credentials are tamper-proof and cryptographically verifiable and can be stored in a wallet.

Verifiable Credentials (VC) are a standard data model and representation format for cryptographically-enabled digital credentials defined by the W3C Verifiable Credentials specification:

  • The issuer is the party that issued the credential (e.g. a university)

  • The holder owns the credential (e.g. student)

  • Verifier to verify the certificate (such as a potential employer)

  • Verifiable presentation is when users share their data with a third party who can verify that the credential was indeed signed by the issuer

Please note that "issuer", "holder" and "validator" are relative here. Everyone has their own DID and the credentials they collect.

Credentials are the cornerstone of reputation, and reputation is a social phenomenon that changes with changing circumstances. One or more credentials may be used as a proxy for an entity's qualifications, capabilities, or authority. Anyone can say to themselves that they graduated with honors from a prestigious university, but that means nothing to anyone else. Certificates held by universities are considered legitimate or prestigious.

While Web3-native badges and X-proof projects do not all adhere to W3C’s VC standards, we can draw similarities from the systems described above.

  • The most direct example is non-transferable NFT badges, which can only be minted by wallets that have completed some on-chain activity. Because all transaction history is on-chain, it is verifiable and tamper-proof from the start. DegenScore quantifies your ape attributes by aggregating your interactions with DeFi protocols and outputs a score using rules on a smart contract. You can mint coins and keep them as a "DeFi Credential" in your crypto wallet. If there was a Degen DAO that was restricted to those with a certain score, then you could present this NFT to the DAO, and then the token gating protocol could verify that you hold it, and you could get into this DAO - Proof of Degen.

  • POAPs * Proof that you attended an event or met someone IRL -- Proof of Attendance/Proof of Encounter.

  • While Otterspace allows DAOs to decide what constitutes meaningful work and award ntNFT badges to their members, Proved requires DAOs to “sign” a claim — proof of contribution — before having their members mint DAO-specific NFT badges for them.

  • 101 At the end of its online courses, once students pass the test, they issue ntNFT – Certificate of Learning.

  • Kleoverse issues Typescript, Rust, or Solidity proficiency badges to users based on their GitHub data - proof of skill.

  • In addition to the access control use cases outlined above, Lit PKPs can also act as a cryptographic notary that Lit Actions checks before signing a certificate. For example, a decentralized education platform could allow course creators to define what counts as passing a test and deploy those conditions as Lit Actions to programmatically issue VCs using their PKP based on those conditions.

2 questions arise here: Which of these certification data points are meaningful, and how do we aggregate them to gain reputation?

The Orange protocol provides a solution to this: integrating these data points into well-defined models through model providers. On Orange, MPs generally refer to platforms that have reputation assessment measures within their systems. "Data providers" allow their data to be used as input to models designed by model providers. MPs then add calculation methods and assign reputation markers to different entities and make these models available for others to use. Dapps can curate and plug into these reputation models for their use cases.

So far, Aave, Gitcoin, Snapshot, DAOHaus, etc. have provided their data to Orange. This data is modeled by them and other projects like Dework, talentDAO, and Crypto Sapiens to provide ntNFTs to members, which unlocks a wide range of opportunities from improving Discord permissions using CollabLand and Guild, to Snapshot’s reputation-weighted governance.

privacy

No discussion about identity infrastructure is complete without considering privacy concerns and the technical primitives that enable it. Privacy is a factor at all layers in the stack. Over the past decade, blockchain adoption has accelerated the development of strong cryptographic primitives such as zk-proofs, in addition to its application in scaling technologies such as rollups, allowing identities to make nuanced, privacy-preserving claims about publicly verifiable information.

Privacy guarantees help us avoid the negative externalities that come with using fully transparent data to make credible claims. Without these guarantees, third parties can initiate interactions outside of the original transaction (e.g., advertising, harassment). Using cryptography and zk-techniques, we can build identity systems where interactions and data sharing are “sandboxed” within well-defined, context-sensitive scopes.

"Normal" verifiable credentials typically come in JSON-JWT or JSON-LD format, and each credential has an external or embedded attestation (digital signature), making it tamper-proof and verifiable, authored by the issuer.

Zk-proofs and new signature schemes enhance the privacy protection features of W3 C VC, such as:

  • Correlation Resistance: Every time a holder shares a credential, this identifier is shared, so every time a credential is presented it means that it is possible for the validators to collude and see where the holder presented their credential and will It is triangulated to an identified person. With Signature Braille, you can share a unique proof of your signature every time without sharing the signature itself.

  • Selective disclosure: Share only the necessary attributes of a VC and hide the rest. Both JSON-JWT credentials and JSON-LD LD-signed credentials require the holder to share the entire credential with the verifier -- there is no "partial" sharing.

  • Composite Proof: Combine the properties of multiple VCs into one proof without having to find the issuer or generate a new VC.

  • Prediction: Allows hidden values ​​to be used in operations, with a value provided by the validator. For example, proving that the credential holder’s account balance is above a certain threshold without revealing the balance, or the often cited case of proving that you are of legal drinking age without revealing your date of birth.

One promising approach is the BBS signature scheme, originally proposed by MATTR in 2020. The proposal allows BBS signatures to be used with the JSON-LD format commonly used by VCs. Holders may optionally disclose statements contained in the originally signed certificate. The proof produced by this scheme is a zero-knowledge proof of the signature, meaning that the verifier cannot determine which signature was used to produce the proof, thus eliminating a common source of correlation.

Iden3 is a zk-native identity protocol that provides a programmable zk framework and open source libraries for zk identity primitives, authentication, and attestation generation. The protocol generates key pairs for each identity using the Baby Jubjub elliptic curve, which is designed to work efficiently with zk-SNARKs for proving identity ownership and claims in a privacy-preserving manner. PolygonID currently uses the protocol for its identity wallet.

Applied zkp is an active area of ​​research and experimentation that has built a lot of excitement from the crypto community over the past few years. In web3, we have seen it being used in applications such as:

  • Private Airdrop: Stealthdrop

  • Private but trustworthy proofs: Sismo (ownership), Semaphore (membership)

  • Anonymous information transmission: heyanon

  • Anonymous voting/voting: Melo

4 Conclusion

Some general implications of this study:

  • Just like how Crypto catalyzed the development and adoption of DPKI, composable reputations that grant online/IRL access will be a catalyst for decentralized identity infrastructure. Currently, credential issuance (proof of x) protocols are fragmented across different use cases and blockchain networks. In 2023, we will see aggregation layers of these (like profiles) mature and gain adoption as a unified interface, especially if it can be used to unlock experiences beyond crypto, like access to events or e-commerce discounts.

  • Key management remains a friction point and prone to single points of failure. This is a clunky experience for most crypto-native users, and a completely inaccessible experience for most consumers. Federation is a user experience improvement to the web1.0 model that allows single sign-on with a per-application username and password. While the user experience for web3 authentication is improving, it still provides a poor user experience, requires a seed phrase, and provides limited recourse if the key is lost. We will see improvements in this area as MPC technology matures and becomes more widespread among individuals and institutions.

  • Crypto infrastructure is meeting user needs in web2. Web3 primitives are starting to integrate with web2 applications and services, bringing decentralized identity to the masses, such as Collab.Land integrating with Nuggets, allowing Reddit users to use their reputation as VC to unlock access. The Auth0 authentication and authorization middleware integrates SIWE as an identity provider and their enterprise customers can now provide wallet login outside of SSO.

  • As data becomes democratized, purification mechanisms need to be validated. Just like indexing protocol The Graph uses a network of curators and delegators to signal the most useful subgraphs (an API for on-chain data), data models around users and reputation for protocols like Ceramic and Orange require time and community involvement To mature beyond DAO and crypto use cases.

  • Privacy Considerations. Projects should carefully consider the impact of public or persistent storage when choosing their stack. Relative to a combination of privacy-preserving VC, ephemeral, and P&DID as well as ZKP for on-chain/off-chain activities, “pure” public data NFTs may be suitable for limited use cases (e.g., some abstraction of on-chain activities) that provide Features such as selective disclosure, key rotation, anti-correlation and revocability.

  • New cryptographic tools like zkSNARKs will be an important part of the next generation of identity infrastructure. While zkp is currently being implemented in isolated use cases, it will require a bottom-up collective R&D effort to focus on application design patterns, ZK circuit implementations for cryptographic primitives, circuit security tools, and developer tools. This is something to keep an eye on.

Decentralized identity is a big project that requires the efforts of the entire ecosystem to converge on standards, iterate on primitives, and check in with each other on the impact of design decisions.