Web3 Identity Stack Explained: Towards a Path of Digital Sovereignty

Original Title: "The Web3 Identity Stack Explained in Length: Towards the Path of Digital Sovereignty"

Original Author: Nichanan Kesonpat, 1kxnetwork

Original Source: The Way of DeFi

Image Source: Generated by Wujiebantu AI Tool

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

Web3 Identity Infrastructure Ecosystem - December 2022

Identity is an emerging attribute composed of data related to an individual, entity, or object. In the physical world, we store this data in our brains in the form of abstract reputation and psychological association. In the digital world, identity is formalized into two parts:

Identifier: A unique set of characters or numbers used to identify a subject (e.g., passport number, Twitter ID, student ID).

Data associated with that subject (such as travel history, tweets and followers, academic achievements).

Creating an identity layer for the internet is challenging because there is a lack of consensus on what it should be and how it should operate. Digital identity is contextual, as we will interact with the internet through various content experiences, and this content exists in at least as many different contexts. Today, our digital identities are mostly fragmented, existing under the control of a few stakeholders whose interest is to prevent us from spilling out from their context into anywhere else.

Businesses see customer relationships as a key asset and are reluctant to give up control over these relationships. So far, there has been no one approach that serves as a force to do so. Even one-time-use throwaway identities are better to them than a framework they cannot control.

Specific industries like finance have unique requirements (e.g., compliance) when it comes to maintaining digital relationships with customers and suppliers.

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

This model creates a power asymmetry between individuals and the parties managing our identities and data. It restricts our autonomy, preventing us from agreeing to selectively disclose our information and port our identities across different contexts for a consistent online and offline experience.

Decentralized identity had been a collective effort even before the rise of Crypto and web3. The overarching goal is to empower individuals to take back control of their identities without relying on centralized, single gatekeepers. Data breaches and diminishing trust in large corporates have made decentralization a core tenet of the next era of internet identity.

 Core Concepts of Decentralized Identity  

Decentralized Identifiers (DIDs) and verifiable credentials are the main building blocks of decentralized identity. DIDs are issued and stored in a Verifiable Data Registry (VDR), serving as a sovereign "namespace" not under central control. Besides blockchain, decentralized storage infrastructure and P2P networks can also act as a VDR.

Here, entities (individuals, communities, organizations) can use a decentralized Public Key Infrastructure (PKI) to authenticate, prove ownership, and manage their DID. Unlike traditional network PKI, it does not rely on centralized Certificate Authorities (CAs) as a trust root.

Identity data is written as a proof, meaning one identity making a "claim" about another (or themselves). The validation of claims is achieved through PKI-enabled cryptographic signatures.

A decentralized identifier has four main properties:

Decentralized: Created without relying on centralized authorities. Entities can create them as they please, maintaining the separation of their desired identity, roles, and interactions across different contexts.

Persistent: Once created, they are permanently assigned to the entity. (Although some DIDs are designed for ephemeral identities.)

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

Verifiable: Entities can prove ownership of the DID or claims about it (verifiable credentials) without relying on third parties, thanks to encryption signatures and proofs.

These properties distinguish a DID from other identifiers such as usernames (unverifiable), passports (non-decentralized), and blockchain addresses (non-persistent, limited resolution).

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

Scheme: The prefix "did" signals to other systems that it is interacting with a DID, not other types of identifiers like URLs, email addresses, or product barcodes.

DID Method: Specifies to other systems how to interpret the identifier. Over 100 DID methods are listed on the W3C website, often associated with their own VDR and having different mechanisms for creating, resolving, updating, and deactivating identifiers.

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

DID Document: The above three parts can be resolved to a DID document containing a way for the entity to self-authenticate, any attributes/claims about the entity, and a pointer to additional data location about the entity ("service endpoints").  

Decentralized Identifier and DID Document Analysis

Crypto's Impact

While Public Key Infrastructure (PKI) has been around for a long time, Crypto has accelerated its adoption through the incentive mechanism of token networks. Something once predominantly used by privacy-focused techies has now become a prerequisite for engaging in the new economy. Users need to create wallets to self-custody assets and interact with web3 applications. With the ICO craze, DeFi summer, NFT frenzy, and the drive for community tokenization, users hold more keys in their hands than ever before. This has led to 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 by talking about wallets. While wallets are still primarily conceived in a financial sense of asset management, tokenization and on-chain history have enabled us to represent our interests (NFT collections), work (Kudos, 101), and opinions (governance votes). Losing a private key is becoming less like losing money and more like losing a passport or social media account. Crypto has blurred the line between what we own and who we are.

However, our on-chain activities and holdings offer a limited view of who we are (and are not privacy-preserving). The blockchain is just one layer of a decentralized identity stack. Other stacks also help address some key questions, such as:

How do we identify and authenticate ourselves in a network and ecosystem?

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 questions will have profound implications for the future shape of the internet over the next few generations.

The following sections will gradually introduce the state of the Web3 identity stack. This includes verifiable data registries, decentralized storage, data mutability and composability, wallets, authentication, authorization, and attestation.

Centralized 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 to issue DIDs. In fact, various public blockchains have W3C DID methods, such as:

Ethereum, did:ethr:public key represents an Ethereum account's identity.

Cosmos, did:cosmos:chainspace:namespace:unique-id represents Cosmos' cross-chain assets.

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

It is worth noting did:pkh:address— a ledger-independent generative DID method aimed at achieving interoperability across blockchain networks. According to the CAIP-10 standard, it is an account ID used for cross-chain key pair expressions.

Fractal is an identity supply and verification protocol designed for applications requiring unique and varying levels of KYC users. Upon completion of validity and/or KYC checks, a Fractal DID will be minted to the corresponding Ethereum address and added to the respective list. Fractal's DID Registry is a smart contract on Ethereum where parties can query a Fractal DID and its verification level.

Kilt, Dock, and Sovrin are specific-purpose blockchain applications for self-sovereign identity. At the time of writing, they are primarily used by enterprises to issue identities and credentials to end-users. To participate in the network, nodes must stake native tokens to process transactions such as DID/credential issuance, define credential schemas, and enforce revocation updates.

Decentralized Data Storage

While general blockchains can also serve as an immutable data source for user data like asset ownership and transaction history (e.g., portfolio trackers and "DeFi score" applications), they may not be suitable for storing most user data as the cost of writing and regularly updating large volumes of information is high and compromises privacy since data is inherently visible.

That said, there are blockchains designed for specific applications such as Arweave* that are built for permanent storage. Arweave rewards miners and pays for transactions to replicate information stored on the network. Miners must provide "proof of access" to append new blocks. A portion of fees is also paid into a Perpetual Endowment Fund that will pay miners in the future when storage costs cannot be covered by inflation and fees.

Ethereum and Arweave are examples of blockchain-based data persistence approaches. On Ethereum, every full node must store the entire chain. On Arweave, all data required to process new blocks and 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 is not permanently replicated and stored by every node. Instead, data persists through agreements with multiple nodes that agree to hold a piece of data for a period of time and must renew the agreement whenever it expires to maintain the data's persistence.

IPFS enables users to store and transmit content-addressed, verifiable data in a peer-to-peer network. Users can store data they desire on their own IPFS nodes, utilize dedicated node clusters, or use third-party pinning services like Pinata, Infura, or web3.storage. As long as one node is storing the data, it exists in the network and is served to other nodes upon request. At the top layer of IPFS is the cryptographic economic layer, such as Filecoin and Crust Network, designed to incentivize data storage for the network by creating a decentralized marketplace 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. The identity wallet Nuggets  has embraced this approach, further decentralizing by enabling merchants and partners to run dedicated nodes.

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

Data Mutability and Composability

Mainstream blockchains, Arweave, and IPFS all ensure immutability, a useful property for static NFT art and permanent record data. However, our interactions with most applications today involve constantly updating our data. Web3 protocols designed for mutable data leverage the decentralized storage layers outlined below to achieve this.

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

When a user updates their profile in a Ceramic-powered app, the protocol validates these updates as a stream, transforms them into a new state, while keeping track of previous state changes. Each update on Ceramic is verified by a DID that can map to multiple addresses, paving the way for users to update their data without servers.

Today, Web2 entities have UI and backends where they store and control user data. Google and Facebook leverage this data to algorithmically personalize our experience on their platforms, further productizing the data they collect. New apps must start from scratch and cannot offer a personalized experience from the get-go, reducing market competitiveness.

Web3 democratizes data, providing a fair competitive landscape for new products and services, creating an open environment for app experimentation and market competition. In a world where users can take their data from one platform to another, app developers don't need to start from a blank slate; they can immediately provide users with a personalized experience. Users can log in with their wallets and authorize apps to read/write to their fully controlled "database."

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

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

The model is a Ceramic Stream, storing metadata about documents' data structures, validation rules, relationships, and discovery information. Developers can create, compose, and remix models to form data compositions as their application's database. This replaces the traditional user tables with centralized UIDs and associated data. Applications can build on publicly controlled datasets rather than managing their own independent tables.

As applications can dynamically define models they will use for a specific environment, the curation market becomes critical as it provides a signal for the most useful data models (patterns defined for social graphs, blog posts, etc.). With a marketplace of these data models, applications can signal to these models to make them more consumable. This will incentivize the creation of better analytics and information graphs from public datasets, enabling further innovation on top of that foundation.

Tableland is infrastructure for mutable, structured relationship data, where each table is minted as an NFT on an EVM-compatible chain. The NFT owner can set access control logic for the table, allowing third parties to perform updates on the database if they have appropriate write permissions. Tableland operates an off-chain validator network that manages table creation and subsequent changes.

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

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

Decouple the application from the data layer, allowing users to port their content, social graph, and reputation across platforms. Applications can tap into the same database and use it in their context, enabling users to have a composable reputation across different contexts.

Wallet

Wallet, in a broad sense, includes interfaces and underlying infrastructure for key management, communication (data exchange among holders, issuers, and verifiers), and claims presentation and validation.

It is worth distinguishing between a crypto wallet (such as MetaMask, Ledger, Coinbase Wallet, etc.) and an identity wallet. A crypto wallet stores blockchain-specific cryptographic keys designed to send/receive tokens and sign transactions. An identity wallet stores identities and allows users to create and provide claims so they can share identity data across applications and services.

Examples of identity wallets include ONTO, Nuggets, and Polygon ID Wallet. Some identity wallets, like Fractal, incorporate validity checks and KYC as part of their onboarding process, allowing users to have a claim to submit to applications that require such information. This is far less common in crypto wallets. Additionally, identity wallets are more likely to support W3C-compliant DIDs, verifiable credentials, and implementations of DIDComm beyond web3 use cases.

WalletConnect  is a communication protocol that allows interaction between a wallet and dapps. As a minimalist, unbiased protocol, WalletConnect has served millions of cryptocurrency users and 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 offer hosted mediator infrastructure, WalletConnect stores information in a "cloud relay" on a relay network and pushes this information to wallets when they come back online.

Authentication

Authentication is the process of verifying the identity of a user based on one or more authentication factors. Authentication factors can be something the user possesses (digital signatures, ID cards, security tokens), something they know (passwords, PINs, secret answers), or something they are (biometrics such as fingerprints, voice, or retina scans).

In a decentralized identity paradigm, users can authenticate themselves with their wallets. In the background, the wallet uses its stored keys to generate digital signatures as a "proof" that the holder possesses the private key associated with that account. Since a crypto wallet can produce signatures, applications offering web3 logins can allow users to authenticate with their Metamask or WalletConnect.

Over the years, crypto users have interacted with dapps by "connecting a wallet." Dapps have had no memory of the connected user and treated them as a blank slate on each website visit.

Today, users engage with dapps in a more nuanced manner. Decentralized identity comes into play here as it allows applications to gain more context about the user, offering a personalized experience while empowering individuals to retain control over their data.

For more sophisticated background interactions, such as loading user preferences, profiles, or private chat messages, an application needs to ensure it's talking to the actual key holder behind the account. While "connecting a wallet" doesn't provide this assurance, authentication standards can. 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 initially proposed by Spruce, ENS, and the Ethereum Foundation. SIWE standardizes a message format (similar to jwt) for users to use blockchain-based account logins. Sign-In with X (CAIP-122) builds upon this, making SIWE an Ethereum-centric implementation of SIWx, generalizing the standard for cross-blockchain operation.

For individuals, this means being able to register or log in with their web3 wallet without needing to create a username and password, mimicking the social login experience with "just a few clicks," while retaining sovereignty over their online identity. Applications can use this as a market strategy targeting a web3-native audience to meet user demands.

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

Unlike the "regular" DIDs described above, Peer DIDs are designed for use between 2 or N known parties. They can serve as unique identifiers for each service and/or interaction. The wallet address in that digital identity can be stored with VCs as verification evidence for each merchant's interaction.

Authorization and Access Control

Authentication confirms a user's identity, while authorization determines what an entity should be able to access and what they are allowed to do with those resources. These two processes are separate but often intertwined in the user experience flow. When logging into a third-party service using social login, a user may be presented with some authorization requests, as shown in the image below:

In the federated identity model, you authorize third-party applications to view or update data you have stored with identity providers (like Google), with them maintaining a list of apps you have authorized and the associated permissions. Web3 authorization infrastructure and standards similarly help achieve this goal, except you own sovereign data and can grant each third party the right to decrypt/read/update data without the need for a centralized intermediary.

With the rise of tokenized communities, web3 token-gated products such as Collab.Land, Guild, and Tokenproof have also emerged. One primary use case of these tools is access control to member-exclusive Discord channels based on roles and reputation for more granular access. Communities can programmatically grant access based on token holdings, on-chain activities, or social validation, rather than manually assigning access.

Lit is a decentralized key management and access control protocol that leverages MPC technology to distribute "shares" of private keys among Lit network nodes. Public/private key pairs are represented by PKPs (Programmable Key Pairs) NFTs, where the owner is the sole controller of that key pair. When certain predefined conditions are met, the owner of the PKP can trigger a network-aggregated key share to have it decrypt files or sign messages on their behalf.

In the context of access control, Lit allows users to define on-chain conditions to grant off-chain resources access. 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). A qualified wallet signs and broadcasts a message to the protocol nodes, which inspect the blockchain to ensure the signer meets the conditions. If the conditions are met, the signer is aggregated key shares to decrypt the file. This same infrastructure can also be used to unlock web2 experiences such as Shopify discounts, locked Zoom rooms and Gather.town spaces, live streams, and Google Drive access.

Kepler organizes data around user-controlled databases ("Orbits"), which represent a designated list of hosts that, as a smart contract, only they can control with their keys. These databases can be managed by trusted parties, cross-host consensus mechanisms, resource owners, and license validity. Anyone using SIWE can instantly leverage private databases to store their preferences, digital certificates, and private files. With support for "bring your own storage" across multiple storage backends, users can self-host or use hosted versions.

Several examples illustrate how applications can use a combination of the aforementioned building blocks:

Orbis is a social networking app ("web3 Twitter/Discord") that uses Ceramic for data storage and updates, with private messages first encrypted via Lit before storage

Using Lit as a decentralized encryption system, delegate who can decrypt your Tableland data 

Kepler can use Ceramic documents as a beacon to route to a private storage area

Create Lit PKPs to let applications "own" a Ceramic stream and grant Lit Actions (code on IPFS) the ability to sign and update databases under arbitrary conditions

CACAO is a standard for representing Object-Capability (OCAP) using Sign-in-With X. It defines a way to record the result of SIWx signed actions as IPLD-based Object-Capabilities (OCAP), creating not only authenticated event acceptance but also composable and replayable authorization receipts.

The authorization method allows users to grant applications fine-grained, well-scoped, and verifiable abilities to view/update their data. Additionally, it can be session-based so they don't have to sign messages on every update but engage in rich interactions on the application and sign once at the end of the session.

Proof and Credential

Here, we reach the top of the decentralized identity infrastructure stack as depicted in the graph.

Some terminology:

Proof refers to proving a statement and signature to be valid, stemming from the need to independently verify events against a record.

Credential is any document detailing information about an entity, authored and signed by another entity or themselves. Credentials are tamper-proof and cryptographically verifiable, storable in a wallet.

A Verifiable Credential (VC) is a tamper-evident digital credential standard data model and representation format defined by the W3C Verifiable Credentials specification:

- Issuer is the credential's issuer (e.g., a university)

- Holder possesses the credential (e.g., a student)

- Verifier verifies the credential (e.g., a potential employer)

- Verifiable Presentation refers to a user sharing their data with a third party, who can verify that the credential was indeed signed by the issuer

Please note that the terms "Issuer," "Holder," and "Verifier" are relative. Everyone has their own DID and the credentials they collect.

Credentials are the cornerstone of reputation, and reputation is a social phenomenon that varies with the context. One or more credentials can serve as a representation of an entity's qualification, capability, or authority. Anyone can claim to have graduated with honors from a prestigious university, but it means nothing to others. Only certificates held by the university are considered legitimate or reputable.

While Web3-native badges and X-proof projects may not all adhere to the W3C VC standard, we can find similarities to the system described above.

The most direct example is a non-transferable NFT badge, which can only be minted by a wallet that has completed some on-chain activities. Because all transaction history is on-chain, verification and tamper resistance are possible from the outset. DegenScore quantifies your ape traits by aggregating your interactions with DeFi protocols and outputs a score based on rules on a smart contract. You can mint and keep it as a "DeFi credential" in your crypto wallet. If there is a Degen DAO restricted to only those with a certain score, you can present this NFT to the DAO, and then a token gating protocol can verify your holding of it, allowing you to enter this DAO — Degen Proof

POAPs * Proof of Attendance Protocol - Proof that you attended an event or met someone in real life

Otterspace  allows a DAO to decide what constitutes meaningful work and issues ntNFT badges to its members, Proved  requires the DAO to "sign off" on a claim before having its members minted a DAO-specific NFT badge - Contribution Proof

101  issues ntNFTs to students upon passing a test at the end of its online courses - Learning Proof

Kleoverse  awards users with Typescript, Rust, or Solidity proficiency badges based on GitHub data - Skill Proof In addition to the access control use case described above, Lit PKPs  can also act as a cryptographic notary, Lit Actions  perform checks before signing certificates. For example, a decentralized education platform could allow course creators to define what qualifies as passing a test and deploy those conditions as a Lit Action, using their PKP to programmatically issue VCs based on these conditions.

There are 2 issues here: which of these attestation data points are meaningful, and how do we aggregate them for reputation?

Orange Protocol provides a solution to this: by having Model Providers (MPs) integrate these data points into well-defined models. On Orange, MPs are generally platforms with reputation measures in place within their system. "Data Providers" allow their data to be used as input for models designed by model providers. The MPs then add computation methods, allocate reputation scores to various entities, and provide these models for others to use. Dapps can plan and incorporate these reputation models for their use cases.

So far, Aave, Gitcoin, Snapshot, DAOHaus, and others have provided their data to Orange. This data has been modeled by them and other projects like Dework, talentDAO, and Crypto Sapiens to offer members ntNFTs, unlocking opportunities ranging from using CollabLand and Guild to enhance Discord permissions to Snapshot's reputation-weighted governance.

Privacy

If we do not consider privacy issues and the technical building blocks for privacy, the discussion about identity infrastructure is incomplete. Privacy is a factor in all levels of the stack. Over the past decade, the adoption of blockchain has accelerated the development of powerful 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 to publicly verifiable information.

Privacy assurances help us avoid the negative externalities of making trustworthy claims with fully transparent data. Without these assurances, third parties could initiate out-of-band interactions unrelated to the original transaction (e.g., advertising, harassment). Leveraging cryptography and zk-technology, we can build identity systems where interactions and data sharing are "sandboxed" within well-defined, context-bound scopes.

“Ordinary” verifiable credentials typically appear in JSON-JWT or JSON-LD formats, with each credential having an external or embedded proof (digital signature), giving it tamper-evident and verifiable properties authored by the issuer.

Zk-proofs and new signature schemes enhance the privacy-preserving features of W3C VCs, such as:

- Anti-correlation: Every time a holder shares a credential, that identifier is shared, so every credential presentation implies that verifiers could collude to see where the holder is presenting their credentials and triangulate it back to an identified individual. With signature blinding, you can share a unique proof of the signature every time, without sharing the signature itself.

- Selective Disclosure: Only share the necessary attributes of a VC, hiding the rest. Both JSON-JWT credentials and JSON-LD signature credentials require holders to share the entire credential with verifiers—there is no "partial" sharing.

- Aggregated Proof: Combining attributes from multiple VCs into one proof without needing to go back to the issuer or generate a new VC. 

- Attestation: Allowing the use of a hidden value in an operation and having a verifier provide a value. For example, proving a credential holder's account balance is above a certain threshold without revealing the balance, or a commonly cited scenario is proving you are of legal drinking age without revealing your date of birth.  

A promising approach is the BBS Signature Scheme, initially proposed by MATTR in 2020. This proposal allows BBS signatures to be used alongside the commonly used JSON-LD format in VCs. Holders can selectively disclose claims from the originally signed credential. The proofs generated by this scheme are zero-knowledge proofs of the signature, meaning verifiers cannot determine which signature was used to generate the proof, thus eliminating a common correlation source.

Iden3 is a zk-native identity protocol that provides a zk programmable framework and open-source libraries for zk identity primitives, authentication, and proof generation of claims. The protocol uses the Baby Jubjub elliptic curve to generate key pairs for each identity, designed to interact efficiently with zk-SNARKs used to prove ownership and claims in a privacy-preserving manner.PolygonID currently employs this protocol in its identity wallet.

The Web3 Genesis begins with the integration of web2 applications and services, bringing decentralized identity to the masses, such as the  Collab.Land integration with Nuggets, allowing Reddit users to leverage their reputation as VC to unlock access. The Auth0 authentication and authorization middleware has integrated SIWE as an identity provider, enabling their enterprise customers to offer wallet login beyond SSO. With the democratization of data, validation mechanisms need to be in place. Just like the Indexing Protocol The Graph uses a network of curators and delegators to signal the most valuable subgraphs (on-chain data's API), the data models of users and reputation around protocols like Ceramic and Orange require time and community involvement to mature, transcending DAOs and crypto use cases. Privacy considerations. Projects should carefully consider the implications of using public or permanent storage in their stack. Relative to privacy-preserving VC, ephemeral and P over DID, and a combination of on-chain/off-chain activities with ZKP, "pure" public data ntNFTs may be suitable for limited use cases (e.g., abstractions of some on-chain activities), providing features like selective disclosure, key rotation, anti-collusion, and revocability. New cryptographic tools like zkSNARKs will be a critical part of the next-generation identity infrastructure. While zkps are currently being applied to isolated use cases, they will require a bottom-up collaborative effort to converge on application design patterns, ZK circuit implementations for cryptographic primitives, circuit security tools, and developer tooling. This is something that needs close attention.

Decentralized identity is a monumental project that requires ecosystem-wide effort, convergence on standards, iteration on primitives, and mutual cross-checking of design decision impacts.

This article covers the infrastructure portion of the decentralized identity stack, with the next article discussing profiles, anti-Sybil, compliance, and the application layer, all built on the building blocks mentioned here.

If you are actively building in this space or have more thoughts on this topic, we would love to hear from you.

Original Article Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia