Registering aspects of your identity on an inherently public and immutable medium such as a blockchain is risky, and needs to be done with care. As discussions around Soulbound tokens and the concept of a wider web3 identity layer become more common, more mechanisms for tokenized identity are emerging, some thought-through, some more ad-hoc. We at Civic believe there is a right way to do this (for details about why we do it at all, see here), and propose the following pillars of tokenized identity. If you are considering integrating tokenized identity into your protocol, seek out a model that meets these requirements.
1. Privacy
There is a strong tendency when integrating a token-based identity system to simply tokenize all the things. If privacy (and gas) were not a concern, the inclination would be to register every possible atomic claim about an identity on chain. Consumers would pick and choose which claims to be interested in and which claimants to trust, in order to derive the ideal cocktail to obtain the result that they want.
Even without storing personally-identifying information (PII) directly on-chain, and instead storing a hash, there are still significant privacy concerns. Firstly, hashes are “pseudonyms” and therefore fall under the auspices of GDPR and similar regulations (see here, here, here) and secondly, the more fine-grained and specific a token type is (think “age token” or “gender token”) the more information it can contribute to identity correlation and the more information it can betray publicly, purely by existing.
This is an issue that web3 will have to come to grips with either way, whether tokenized-identity mechanisms are used or not, as long as it maintains its stance on full public transparency. If someone interacts publicly (e.g. by voting) with one DAO that limits access to over-35s, another that limits access to women, and trades on a DEX that is only available to people in the EU, all under the same wallet, then it does not matter how those constraints are implemented, the information that this wallet belongs to an over-35 European woman is discoverable purely through that wallet’s interactions on-chain. Add to that the increasing trend of issuing NFTs for attendance at events, membership in real-life clubs, etc, and suddenly even things that are not intended as identity tokens become identity tokens.
At Civic, we take the position of being as broad as possible with Civic Pass, while allowing for flexibility and fine-grained access control via off-chain Verifiable Credentials. We are circumspect about which pass types we choose to issue, and in general, steer clear of issuing identity tokens based on specific claims or aspects of an owner’s identity, in favor of broader access-control-like passes such as proof of uniqueness/humanity, or simple CAPTCHA-based bot-resistance.
2. Decentralization
In any token-based gating mechanism, the token issuer, the “mint key”, holds the power. If a platform is gated by an NFT, the issuer of an NFT holds the power to allow or deny access to a platform. If that key holder is a single individual or organization, then it is not decentralized. You have a single point of control, a single point of trust, and a single point of failure, if that key disappears.
The mint key needs to be a multisig controlled by a DAO of some kind. The Gateway Protocol used by Civic Pass includes this decentralization layer directly through the “gatekeeper network” pattern. Each pass type is its own network, and each network is a separate DAO. Tokens issued by members of the network are indistinguishable and interchangeable. When you trust a Civic Pass of a particular type, you are trusting the network, not simply Civic itself. A network is bootstrapped by Civic but not owned by Civic.
3. Interoperability
One of the drivers of success in Web3 so far has been the emergence of standards, allowing clients and smart contracts to be based on generic tools rather than being bespoke to individual projects. ERC20 is a perfect example of this. While not perfect, its presence and almost ubiquitous adoption (in the Ethereum space) has enabled, from a technical perspective, practically all of DeFI.
The NFT space is somewhat more fragmented, with standards such as ERC721 and ERC1155 meeting different use-cases, and in fact, we are often asked whether Civic Passes could be issued as NFTs.
While there are similarities, we believe an identity token or pass spec requires features that NFTs typically do not include, such as the ability to expire or freeze, as well as a “DAO by default” component (see “Decentralization” above), and the Gateway Protocol whitepaper, to which we contributed, has these features built in.
However, diversion and fragmentation of standards leads to interoperability problems, until clear winners emerge, and reduce the reusability of tokens and tools built to handle them. This is why we are working on a “derivation tool”, to allow Civic Pass holders to convert their passes to other standards (such as NFTs) in a secure and trustless way, in the spirit of the fifth law of “The Laws of Identity”, the prescient canon of digital identity.
Another aspect of web3 interoperability is cross-chain support. The future of multichain one, and a user should be allowed to take their identity with them across chains that they interact with. Likewise, if they have the pass allowing them to interact with a DeFi protocol on chain 1, they should be allowed to interact with an equivalent one on chain 2. If they have outstanding loans against their identity on chain 1, they should not be allowed to take out more on chain 2.
Civic Pass is built from the ground up to be multichain, and as we build out support for various chains, we are working on cross-chain mechanics in the following ways:
- Reusable credentials: We issue reusable verifiable credentials, which allow a user to associate a wallet on a different chain with their identity, by re-presenting their credentials.
- DIDs: We allow a user to add keys from multiple chains to their decentralized identifier (DID) on-chain, so that passes can be trustlessly reissued on new chains.
The first option maximizes privacy, ensuring that only the pass issuer, Civic, knows about the connection between the wallets. The second option maximizes trustlessness, as the user can essentially self-serve their pass on the second chain, by virtue of linking their wallets to one identity. The second option is also more suitable for cases such as proof of uniqueness, where linking multiple wallets to a single pass requires that link to be discoverable on-chain in order to trust it.
4. Pluralism of Identity
A user should not be tied to a single public key. Among the many reasons for this are security (key recovery, avoiding the need to carry around and sign with cold wallets) and privacy (users may want to present a different aspect of their identity to different audiences, or may not want to correlate their activity on one protocol with their activity on another.
As described in Interoperability, Civic uses DIDs and reusable Verifiable Credentials, to allow a user to associate their passes with multiple keys, or recover their identity if they lose wallet access. In general, Civic is committed to the idea that your Web3 identity is more than just your public key and is building the Civic Pass infrastructure based on DIDs.
Conclusion
Tokenization is an important part of Web3 identity, but digital identity must ensure that the core values of human beings are respected. While many challenges may be addressed as the industry develops the technology (see e.g. zero-knowledge proofs), the biggest challenge of all is to set up a system that can be as flexible and nuanced as we need it to be, so that humans may be protected both in the real world and within Web3. By setting forth these pillars of tokenized identity, we hope to draw attention to a bigger and better vision of a system that protects humans while offering the best of the digital world.