Credentials are the building blocks of our identity, used to define reputation, experience, and abilities. Before we dive deep. Let us give some clear definitions:
Issuer - The individual or entity that is making a claim(s) about another individual or entity.
Claim - An attestation being made by an issuer.
Claim Structure - A data model created that organizes the claims made by an issuer.
Recipient- The one who the credential is issued to. Usually, this is the party that the claim is about.
Consumer - The entity or application reading or using the credentials for their purposes.
Credential - A claim or series of claims made by an issuer that can be verifiably proven.
Credentials in the traditional world take many forms, including degrees, certifications, professional licenses, and other types of documentation. These credentials define our existence from birth to our death (literally!). The first credential is a birth certificate. The “claims” that we have are the name of the child, the names of the parents, and the time and place of birth. Given that credentials organize a series of quantitative or qualitative pieces of information into a claim, they can be composed together like legos to issue other credentials. In our first blog, Sanket showed how a person’s Social Security Number, birth certificate, passed driver’s test, and picture are needed to issue a driver’s license to said person.
Here are some examples of credentials in the traditional world (insert images of drivers license, college degrees, medical licenses, and an AWS certificate).
How do credentials work in web2?
In web2, credentials are stored and verified through centralized databases and servers. This means that an individual's credentials are stored on a proprietary server which can only be accessed by authorized parties. This leads to issuers coupling as verifiers, making the process significantly more inefficient and ineffective (see chart below for process). Furthermore, it prevents normal individuals from issuing and managing credentials because they do not have the capacity to run their own servers nor the infrastructure for storing. As Sanket previously stated, “Storing the data in (an issuer’s) respective database allows them to confirm that you indeed are the person who this claim is about.”
For example:
Universities and schools issue credentials such as degrees and transcripts to students who have completed their programs of study.
Professional associations and licensing boards issue credentials such as professional licenses and certifications to individuals who meet certain requirements and pass necessary exams.
Government agencies issue credentials such as driver's licenses, passports, and birth certificates to individuals who meet certain requirements.
In general, the process for issuing and managing credentials in web2 can be demonstrated through this example:
Olivia applies to a job at Google.
As part of Google's recruitment process, they must complete a verification of the applicant’s educational history. For Olivia, this means she needs to provide proof that she attended Harvard University - the university listed on her resume. Harvard takes the request, processes the information by checking it against their central database to verify the individual’s status as an Alumni and their transcript.
Harvard then ensures all information in the database is valid, and will generate a proof of the individual’s record with the University.
Harvard will share this proof with Google.
NOTE: Since this proof is valid for Harvard only, Google must repeat this outreach process with every other “claim” on Olivia’s degree.
Why are credentials in web2 limiting?
Security: Web2 credential systems are vulnerable to hacking and tampering, as they rely on centralized databases and servers. If the central database or server is compromised, an individual's credentials could be altered or falsified, leading to fraud and misrepresentation of qualifications. More importantly, privacy infringement is a common issue within web2. Known social platforms and government entities collect private consumer information, leaving the end-user with no say in how their data is managed.
Verification/Efficiency: Web2 credential systems are difficult to verify. There are three main reasons. The first reason is that credentials issued from web2 platforms operate within closed-data silos. Making them inaccessible. The second is the de-facto reliance on the issuing party to verify any credentials (as seen in the Google-Harvard example above. Lastly, time. Inefficiencies pile up, and for most organizations looking to move fast this becomes a large cost.
Accessibility and portability: With traditional credential systems, it can be difficult for individuals to access and share their credentials with others. This is because credential data is not owned by the user, thus they do not have rights to permission the information.
Cost: Traditional credential systems often require significant resources to maintain. Considering that credentials issued in web2 are hosted on centralized servers, it implies that each institution is required to build and maintain their own servers.
Credentials in web3
Web3 technology, also known as decentralized technology, is a type of internet technology that utilizes blockchain and decentralized protocols. This technology allows for greater security and transparency compared to traditional web2 technology.
Tamper-Proof: Web3 technology improves credential systems by providing a secure and tamper-proof way to store and verify credentials.With web3 technology, credentials can be stored on a decentralized blockchain, making them much more secure and resistant to tampering.
Transparency: Another benefit of web3 technology is that it allows for greater accountability in credential systems. All credentials can be easily and transparently verified via a public blockchain (digital ledger), ensuring that only valid and accurate credentials are accepted.
Portability and Composability: Web3 technology enables greater accessibility and portability of credentials. Individuals can easily access and share their credentials through their digital wallets or other decentralized platforms. Given that data is not “controlled” by an outside arbitrator, the recipient of a credential can choose how it used.
Composability is best seen in web3 with token based access controls around communication channels or product features.
Cost: Technology within web3 is far more scalable as it relies upon decentralized networks, most notably decentralized storage systems like Arweave or IPFS. This allows global participants to leverage their hardware to aid in the maintenance of network data, offloading the burden of maintenance and payment from one centralized entity.
Control and Ownership: Your keys, your crypto. A popular term that is emphasized in web3 communities. What does this mean? You have full control over all data and information associated with your digital assets as well as your identity.
Overall, web3 technology has the potential to significantly improve credential systems by providing a secure, transparent, and accessible way to store and verify credentials. As web3 technology continues to evolve and become more widespread, it is likely that we will see more and more organizations and individuals turning to decentralized credential systems.
What are the standards for credentials in web3?
Now that we understand what a credential is, how credentials work in web2, how they are working in web3, let us dive into the most common standards in use today.
NFTs (Non-Fungible Tokens)
These are unique digital tokens that cannot be replicated, altered, or replaced. They live exclusively on top of the blockchain to ensure authenticity and ownership. NFTs were made popular in 2021/2022, when several projects released one-of-one PFPs and exclusive digital art. The strengths of an NFT relies on the fact that all information associated with it is publicly accessible. NFTs are associated directly with wallets which serves as the only way to sign and own digital assets. NFTs are also fully transferable, making it hard to prevent individuals from selling “valuable” claims to others who did not receive them.
VCs (Verified Credentials)
VCs are based on the w3c credential model since 2017, which promotes tamper-proof, privacy preserving, and user controlled JSON files that must be verified cryptographically. This is often done by sending proofs to another individual who must use public-key decryption to access said credential information. VCs are best associated with highly sensitive data like bank information, passports, or licenses. Note VCs do not have the same public verification as NFTs, most information is stored off-chain and locally (in centralized containers), and requires the recipient to allow for verification (one-way demonstrable). If said information were to be stored publicly on a blockchain-ledger, sensitive information could technically be accessed by bad actors. Lack of privacy and control for user’s is a large reason why the permanence of blockchains infringes upon our individual sovereignty.
SBTs (Soulbound Tokens)
These are the same as NFTs, but a key difference in its characteristic is that SBT, are soul-bound. Meaning as an asset they are non-transferable or non-destroyable. This allows one's activity and reputation garnered across decentralized applications be solely tied to their wallet address to establish provenance. Building upon what we know about NFTs and how information is made publicly accessible to all, Vitalik alluded to how ZKPs (Zero-Knowledge Proofs) are necessary for more private information to be put on chain without revealing said sensitive information. This would allow someone to verify that an individual meets certain requirements while providing “zero-knowledge” to any other information or specific details.
Is this enough? The Gateway to Credentials!
Much of the technology mentioned in the section above is being built, improved, and tested. Each standard has its own benefit today, and promises more innovations in the future. We at Gateway do not believe that the solution must be one or the other. Instead, we look at verified credentials and NFTs as very synergistic. In fact, the team is harnessing the benefits of both SBTs and VCs to create a credential standard and lifecycle management protocol. We will be releasing more details on this in our next blog post called “Gateway’s Credential Protocol”.
For now we are looking to leverage Arweave to help store credential metadata and issuer schemas (data models for credentials) and encrypt the resulting claims using Lit Protocol. This allows us to ensure our data standard is privacy preserving and user-controlled. Additionally, we allow recipients to mint SBTs on any chain they wish, while not requiring the data to be made fully-public. Make sure to follow us on Twitter for more updates and educational content on credentials! Be on the lookout for new credentials that you can earn on the Gateway dApp today by creating your profile on mygateway.xyz.
Super
Good