Chuy Cepeda
- Oct 29, 2022
- 9 min read

6 recommendations for implementing a Blockchain identity project

By Lucas Jolías, Ana Castro y Jesús Cepeda

When thinking about an identity and credentials project, you may have doubts such as which blockchain to use, how to validate the identity of citizens, and whether to develop your own blockchain or use one from the market. In this brief guide, we will provide answers to some of these concerns, with the aim of clarifying some obstacles that may arise in the implementation process

1. Define an authentication and/or identity verification method.

The first thing we must define is how we are going to identify the citizen. As we have mentioned in other publications, our position is that the identity belongs to the citizen through a decentralized system like blockchain, but the validation of their identity is still done by the State (at least in Latin America). For this, there are several possibilities:

National authentication service: in various countries there are national-level authentication systems that can be integrated by third-party applications (government or private). For example, in Argentina there is Autentic.ar, which is the presidency's service to verify the identity of citizens against various State authentication providers; in Uruguay there is something similar under gob.uy, and in Brazil the same through its unique gov.br login. In Mexico, there is authentication with advanced electronic signature, used by various agencies and municipalities, but it is not a full-fledged authentication system like those mentioned above.
Custom development: a government can also choose to have its own validation system and not depend on a national government. For this, the government must develop or integrate a biometric recognition system that allows it to securely register its citizens and build a database that contains their validated records. These types of systems used to be quite expensive, but in recent years, solutions have emerged that allow citizens to be biometrically validated easily and at a low cost. We recommend this type of option once identity projects begin to scale up.
Presential validation: although digital validation is optimal, we should not rule out the possibility of validating our citizens in person. In many cases, it is advisable to have this option as a complement to digital validations for two reasons: a) digital systems often fail and b) there are age groups that often prefer to do it in person. What many governments have done is to generate two levels of security associated with my identity, where the first level is obtained simply by generating a user and password (without validation) and the second level is obtained by validating my identity with a government official in person. As we can see, there are several options to validate the identity of our citizens. Taking into account the different profiles, it is advisable to consider these options as complementary and not exclusive since more options can improve the user experience. Currently, decentralized identity validation methods are being developed, where it is no longer the state that guarantees that a person is who they say they are, but rather peers (friends, family, acquaintances, etc). This type of innovation is being tested in the crypto world and has great potential, although we still consider it premature for procedures with governments.

2. Define the infrastructure (blockchain) of the project.

Firstly, we must avoid the idea of building "our own blockchain." On many occasions, we think that it is necessary to develop a particular infrastructure for public sector projects. Developing a decentralized infrastructure takes time and money, but mainly involves the commitment of dozens or hundreds of actors over time. Let's think of blockchain as a highway (infrastructure) on which different cars (projects, applications, etc.) will run. Does it seem like a good idea to invest in a highway for 2 or 3 cars per day? Developing a specific blockchain would make sense if we already have dozens or hundreds of projects, a mature ecosystem, and the long-term commitment of its members. The second decision will be what kind of infrastructure to use, and here there are flavors for everyone. There is no blockchain per se that is better than another, but each one has characteristics that will fit better or worse for your project. Public blockchains tend to be more secure, usually have a community behind them that gives "life" to the infrastructure, and are resistant to censorship, but they also tend to have very high costs for developing social projects. The emergence of Layer 2 or second-layer on public blockchains that will lower the cost of each transaction is promising, but their development is still in its infancy. Permissioned blockchains are commonly smaller, have many fewer nodes, and are not as resistant to censorship, but they commonly have no costs, or these are very low. If you are going to work on a pilot experience level, you will not find many difficulties when working with one or another blockchain, but things change if you think about scalability. We are going to a world where there will not be a single blockchain but a multiplicity of infrastructures with different characteristics and magnitudes. Regardless of whether we work on a public or private blockchain, we must consider the interoperability between them, what standards they adopt, and how we avoid getting "stuck" in a single infrastructure. For example, there are private blockchains like LACChain that were built following public blockchain standards like Ethereum, allowing us to have compatible standards and develop projects that can migrate in the future.

3. Integrating an identity wallet.

Once we have defined the authentication method and the infrastructure to use, we must define what type of wallet we are going to integrate. Here we must make several decisions, but there are two that we consider central:

If we are going to use a "non-custodial" wallet (where the private key is stored on the citizen's device and the wallet provider does not have access to it) or an app where the provider has access to the private key (technically we would not be talking about a wallet);
If we are going to use a cryptocurrency wallet or a wallet specifically for verifiable credentials.

Each decision has its pros and cons. For example, if we decide to use a non-custodial wallet (where the citizen's private key is stored on their device and the wallet provider has no access to it), we are respecting the ideal of decentralization since only the citizen has access to manage their credentials. However, if they lose their private key or recovery phrase, they may lose their credentials (although recovery methods exist today). On the other hand, if they decide to use a custodial wallet, the citizen will not have any problems if they lose their keys, but their private key is held by the wallet provider, who ultimately manages the citizen's identity. We have the same ambiguity if we decide to use a cryptocurrency wallet, which has a much more mature development but was designed for another purpose, or if we decide to use a wallet that supports verifiable credentials, which has a much more user-friendly experience for government procedures.

Our recommendation is to start with wallets that have been specifically designed for procedures and credentials with organizations and governments, and as the population becomes familiar with the use of different wallets, then we can integrate cryptocurrency wallets. This is because if we integrate crypto wallets from the beginning, non-specialized users may have great difficulty managing their information and achieving the goal (completing a government procedure). The decision to use custodial or non-custodial wallets has a lot to do with the recovery methods offered by each wallet and the degree of autonomy a citizen can have. Our perspective is that custodial wallets do not respect the idea of Decentralized Identity. Ultimately, although it is initially a decision of each government, in the long term, we believe that the decision to use one wallet or another should be the citizen's choice. It is the citizen who must decide what type of wallet to use, which is why services like Wallet Connect are crucial to integrating various wallets and giving the citizen the final say.

4. Define protocol and design of verifiable credentials.

The decision of a wallet also depends on the type of standard or protocol we choose for our verifiable credentials. Today we can choose from two major protocol families: on the one hand, verifiable credentials and on the other, non-fungible tokens (NFTs). Within the world of verifiable credentials, there are several standards, with the most well-known being the W3C, although several others have emerged in recent years that add some modifications or improvements to the W3C standard, such as Blockcerts, OpenCerts, Open Attestation, LACChain, or the recent GovTech Protocol promoted by OS City. Verifiable credentials allow both the information contained in the credential and the issuer and recipient of it to be validated, and they have a considerable development in terms of standards and rules.

With the rise of NFTs in the world of art and collectibles, more and more wallets are integrating these types of protocols, which would allow a credential or title to be transferable without the need for an intermediary's bureaucratic process (the State). Due to the very nature of non-fungible tokens, they can be very useful for those certificates that are transferable, such as a title to a car, real estate, or land. Our recommendation is to start by integrating procedures that end with a non-transferable credential (an educational degree, a permit, a driver's license, etc.) and digitizing them following the standards of a Verifiable Credential. Without a doubt, in the medium term, NFTs will have a positive impact on reducing the bureaucratic burden of the State and lowering transaction costs for various operations in our daily lives.

5. Define the first procedure

Once we have defined the infrastructure, wallet, and credential standards, we could say that we have already made a great deal of technological decisions. Now, we must focus on public policy, and the big question is, where do we start? Each government has its peculiarities, and there are various criteria to consider (political, administrative, legal, etc.). We propose taking two variables that help us define where to start:

impact, that is, procedures that have greater or lesser relevance for the daily life of our citizens; and
simplicity, that is, procedures that do not have a very long process, that are attended by a single area, that have few requirements, etc.

In the continuum of these two variables (low and high impact / simple or complex procedures) we can locate all the procedures of our organization and begin to define where to start.

Usually, procedures with higher impact have a greater bureaucratic burden as the government needs to validate a series of assumptions about us or our activities. For example, opening a new business or industry has a high impact on my city or country, but the procedure has a very complex bureaucratic burden in most cases. On the other hand, a certificate of debt-free status can be managed with few requirements, but its impact on the daily life of our neighbors is much lower.

Whether we start with complex procedures of high impact or with simple procedures of low impact will depend on the political commitment of the institution, the involvement of the various government areas, and their aversion to change. If we have the support of the highest political authority, an involved technical team, and the commitment of the service-providing areas, then we can tackle those complex procedures with greater impact.

Otherwise, it is best to start with those procedures of lower complexity and, as we show results, scale up to those of greater impact. An incremental strategy is usually convenient to involve other areas that are not so familiar with technology in general and blockchain in particular.

6. Public Launch and User Experience

The public launch of the experience should serve not only to make political announcements but also to raise awareness and educate citizens on blockchain, wallets, and Web 3. Part of bringing autonomy to our citizens is for them to internalize certain practices that will allow them to not depend on various institutions and protect their private information, and for this, we must do strong training and communication work. One of the biggest challenges is in managing private keys, how we prevent their misuse and how we help recover a wallet. For this, it is essential to accompany the implementation of public policy with a proper communication strategy, courses, tutorials, among others. Let's remember that much of the Web 3 revolution is due to its community, and the community is transcendental to sensitize and move from initial adopters to massive adoption.

The involvement of the highest political authorities in project communication is important to show a willingness to change, but this alone will not be enough to generate this change. Communication strategies must aim to generate a cultural change not only outside our organization but mainly inside, within the structures of bureaucracy. Cryptocurrency and blockchain communities are increasingly important and global, and we must take advantage of this to improve and involve the common citizen in this change. In this case, more than communicating a government action, we must seek strategies for generating communities around digital identity and the services offered. In the world of Web 3, the government is just another actor, and its transformative capacity will depend on its own community. The success of the project will depend largely on the social appropriation that the ecosystem makes and then expands it to the rest of the community.