Original title: "Towards Digital Self-Sovereignty: The Web3 Identity Stack"

Author: Nichanan Kesonpat, 1kxnetwork

Compilation: The Way of DeFi

 

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 the related development of privacy primitives. Proof-of-Personhood, compliance, and application layers will be covered in future articles.

Web3 Identity Infrastructure Ecosystem - December 2022

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 following, 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 a power asymmetry between individuals and the parties that manage our identities and data. It limits our autonomy and prevents us from consenting, selectively disclosing our information, and porting our identities across different environments for a consistent experience 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.

 

The core concept of decentralized identity

 

Decentralized identifiers (DIDs) and proofs are the main building blocks of decentralized identity. DIDs are issued and stored in verifiable data registries (VDRs) as autonomous "namespaces" that are not centrally managed. In addition to blockchains, decentralized storage infrastructure and P2P networks can also serve as VDRs.

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: Not dependent on a centralized institution to create. Entities can be created as they wish, maintaining the separation of their desired identities, roles, and interactions in different environments.

  • Persistent: Once created, they are 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 a third party, thanks to cryptographic signatures and attestations.

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

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

  • Scheme: The prefix “did” tells other systems that it is interacting with a DID, rather than some other type of identifier like 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 above 3 parts can be parsed into a DID file, which contains how the entity can authenticate itself, any attributes/claims about the entity, and pointers to where additional data about the entity can be located ("service endpoints").

The Anatomy of Decentralized Identifiers and DID Documents

 

The 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 (and not privacy-preserving) view of who we are. Blockchain is just one layer of the decentralized identity stack. The rest of the stack also helps solve important problems, such as:

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

  • How do we prove things about ourselves (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?

The solutions to these problems will have profound implications for 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.

Decentralized Identity Infrastructure Stack

 

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:

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

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

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

It is worth noting that did:pkh:address is a ledger-independent generation DID method designed to achieve interoperability of 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 validity and/or KYC checks are completed, 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. At the time of 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 the native tokens to process transactions such as issuance of DIDs/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 application-specific blockchains, such as Arweave*, that are designed for permanent storage. Arweave pays miners block rewards and transaction fees in exchange for copying the information stored on the network. Miners are required 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 are not covered by inflation and fees.

Ethereum and Arweave are examples of blockchain-based approaches to data persistence. On Ethereum, each 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 by simply 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 hold the data they want on their own IPFS node, leverage a dedicated group of nodes, or use a third-party "pinnin" service like Pinata, Infura, or web3.storage. As long as there is a node storing the data, it exists in the network and is available to other nodes when they request it. On top of IPFS are cryptoeconomic layers like Filecoin and Crust Network, which aim to incentivize storing 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 GDPR/CCPA’s right to be forgotten by allowing users to delete their data stored on the network. Identity wallet Nuggets takes this approach and further decentralizes it by letting merchants and partners run specialized 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 a file) to ensure data availability even if some nodes are offline. They also have built-in incentive structures using native tokens for storage.

Data Mutation and Composability

General purpose blockchains, Arweave, and IPFS all guarantee immutability, which is a useful property for data like 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 enable this, leveraging a decentralized storage layer underneath.

Ceramic is a protocol for decentralized data mutation and composability that works by turning immutable files in persistent data storage networks like IPFS or Arweave into dynamic data structures. On Ceramic, these "data streams" act 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 an application powered by Ceramic, the protocol verifies these updates as a stream, transforming it into a new state while keeping track of previous state changes. Every update on Ceramic is verified 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 the 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 must start from scratch and cannot provide a personalized experience from the beginning, 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. The nodes in the graph are accounts (DIDs) or files (data streams). The edges in the graph represent the 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 a document's data structure, validation rules, relationships, and discovery information. Developers can create, combine, and remix models to form a combination of data that serves as the database for their application. This replaces the traditional user table with a centralized UID and associated data. Applications can be built on top of 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 access control logic for a table, allowing third parties to perform updates on the database if that party has appropriate write permissions. Tableland runs a network of off-chain validators that manage the creation and subsequent mutation of tables.

On-chain and off-chain updates are handled by a smart contract that points to the Tableland network using a baseURI and tokenURI. Through Tableland, NFT metadata can be mutated (using access control), queried (using SQL), and combined (with other tables on Tableland).

Similar to how smart contract standards like ERC-20 and ERC-721 give dapps a shared language about how we create and transfer tokens, data model standards give applications a shared understanding of profiles, reputations, DAO recommendations, and social graphs. Through an open registry that anyone can submit to, this data can be reused by multiple applications.

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, like 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-endorsed DIDs, Verifiable Credentials, and DIDComm implementations, as well as use cases beyond web3.

WalletConnect is a communication protocol that connects wallets to wallets and dapps. As a minimalistic, unbiased protocol that already serves 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 by connecting “wallets.” The dapp has no memory of the connected user and treats them like 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 Wallet does not provide this assurance, the authentication standard does. Authentication establishes a session with the user and allows the application 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 log into blockchain-based account services. Sign-In with X (CAIP-122) builds on this, making SIWE an Ethereum-centric implementation of SIWx, generalizing the standard to work 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 web3-native UX improvement. However, this will expose users to correlation and tracking issues that have become very pernicious in web2. Authentication via Peer DIDs or self-certified identifiers could 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 the user's identity, while authorization determines which 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 flow. After logging into 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 members-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 can upload a file to Arweave or AWS, encrypt it with Lit, and define a set of conditions (such as NFT ownership). Eligible wallets sign and broadcast a message to the protocol node, which checks the blockchain to ensure that the signer meets the conditions, and if so, aggregates 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 broadcasts, and Google Drive access.

Kepler organizes data around user-controlled databases ("Orbits") that represent a list of designated hosts of data as a smart contract that only their keys control. 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 private databases 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 hosted version.

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

  • Orbis is a social networking 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 storage areas

  • Create Lit PKPs to let applications "own" a Ceramic stream and grant Lit Actions (code on IPFS) the ability to sign and update the database if arbitrary conditions are met

CACAO is a standard for representing chain-agnostic object capabilities (OCAP), created using Sign-in-With X. It defines a method to record the results of SIWx signing operations as object capabilities (OCAP) based on IPLD, creating not only authenticated event acceptance, but also composable and replayable authorization receipt for verifiable authorization.

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.

Certification and credentials

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

Some terminology:

  • Attestation is the proof that a statement or signature is valid and arises from the need for independent verification of the events recorded.

  • A credential is any document detailing information about an 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 has the credential (e.g., student)

  • Verifier verifies the certificate (such as a potential employer)

  • Verifiable presentation means that users share their data with a third party, and the third party can verify that the credential is 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 context. One or more credentials can be used as a proxy for an entity's qualifications, competence, or authority. Anyone can say for themselves that they graduated with honors from a prestigious university, but this means little to anyone else. It is the credentials held by a university that 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 straightforward example is a non-transferable NFT badge that 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 smart contracts. You can mint and keep it in your crypto wallet as a "DeFi credential". If there is a Degen DAO that is limited to those with a certain score, then you can present this NFT to the DAO, and the token gating protocol can then verify that you hold it and you can enter this DAO - Degen Proof

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

  • Otterspace allows DAOs to decide what constitutes meaningful work and issue ntNFT badges to their members, Proved requires a DAO to “sign” a claim before having its members mint DAO-specific NFT badges for it — Proof of Contribution

  • 101 issues ntNFT – a certificate of learning – at the end of its online courses once students pass the test.

  • Kleoverse issues Typescript, Rust or Solidity proficiency badges to users based on 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 check before signing a certificate. For example, a decentralized education platform could allow course creators to define what counts as a passed test, and deploy those conditions as a Lit Action that programmatically issues VCs based on those conditions using its PKP.

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

Orange Protocol offers a solution to this: integrating these data points into well-defined models through Model Providers. On Orange, MPs are generally platforms that have reputation assessment measures within their system. “Data Providers” allow their data to be used as input to models designed by Model Providers. MPs then add calculation methods and assign reputation tags to different entities and make these models available to others. Dapps can curate and plug into these reputation models for their use cases.

So far, Aave, Gitcoin, Snapshot, DAOHaus, and others have contributed 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 licensing with CollabLand and Guild, to reputation-weighted governance for Snapshot.

privacy

No discussion of 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 usually come in JSON-JWT or JSON-LD format, each with an external or embedded attestation (digital signature) making it tamper-proof and verifiable, written by the issuer.

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

  • Anti-association: Every time a holder shares a credential, this identifier is shared, so every presentation of a credential means it’s possible for a verifier to collude to see where the holder presented their credential and triangulate it to an identified person. With Signature Braille, you can share unique proof of the signature every time without sharing the signature itself.

  • Selective disclosure: only necessary properties of the VC are shared, while the rest are hidden. 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 can selectively disclose claims in the credential that was originally signed. The proofs produced by the scheme are zero-knowledge proofs of the signature, meaning that the verifier cannot determine which signature was used to produce the proof, eliminating a common source of association.

Iden3 is a zk-native identity protocol that provides a programmable zk framework and open source libraries for zk identity primitives, authentication, and claim 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 yet trustworthy proofs: Sismo (ownership), Semaphore (membership).

  • Anonymous information transmission: heyanon

  • Anonymous voting/voting: Melo

 

in 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 point of friction and prone to single points of failure. It is a clunky experience for most crypto-native users and a completely inaccessible experience for most consumers. Federated identity authentication is a UX improvement to the web1.0 model, allowing single sign-on with a username and password for every application. While the UX of web3 authentication is improving, it still provides a poor UX, requires a seed phrase, and offers limited recourse when keys are lost. We will see improvements in this area as MPC technology matures and is promoted among individuals and institutions.

  • Crypto infrastructure is meeting the needs of users 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 stake their reputation as a VC to unlock access. Auth0 authentication and authorization middleware integrated SIWE as an identity provider, and their enterprise customers can now offer wallet logins in addition to SSO.

  • As data is democratized, sanitization mechanisms need to be validated. Just as 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 will need time and community engagement to mature beyond DAOs and crypto use cases.

  • Privacy considerations. Projects should carefully consider the impact of public or permanent storage when choosing their stack. Relative to privacy-preserving VCs, ephemeral and P DIDs, and combinations of ZKPs for on-chain/off-chain activities, “pure” public data ntNFTs may be suitable for limited use cases (e.g., abstraction of some 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 zkPs are currently being applied to isolated use cases, it will require a collective bottom-up R&D effort to focus on application design patterns, ZK circuit implementations for cryptographic primitives, circuit security tools, and developer tooling. This is something to watch closely.

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.

This article covered the infrastructure part of the decentralized identity stack, the next article will discuss the profile, sybil resistance, compliance, and application layers, which are all enabled by the building blocks mentioned here.