Hanging in there? We’ve covered a lot in the past two posts. But don’t worry, we’re in the final stretch. In this installment of our series on Verifiable Credentials we’ll talk about the different implementations of credentials, the lifecycle of a credentials and finally, we’ll cover some of the sexy (to nerds like us, anyway) cryptographic techniques we can use with VCs, such as zero-knowledge proofs. Are you ready? Ok, let’s go!

Now, it would be great if Verifiable Credentials were just Verifiable Credentials and that was the end of it, but alas, the nuance continues. The Verifiable Credential spec from the W3C leaves some of the implementation details up to interpretation, meaning that while VCs are a standard, there is still some ongoing experimentation. There are 2 main types of Verifiable Credentials: ones that are based on JSON Web Signatures and ones that are based on Linked Data Proofs. The ones based on JSON Web Signatures come in the form of something called a JSON Web Token, or JWT for short. And the others you’ll often see referred to as JSON-LD.

JWT based VCs are simpler and based on an older, more widely adopted standard. This makes JWT based VCs easier to work with as there exists more developer tooling. However, because of this simplicity, JWT based VCs can’t do some of the more fancy things we will talk about. Additionally, JWT based VCs lack semantic clarity. What that means is that when a Verifier’s web app is attempting to interpret a credential that a user is disclosing to it, the web app doesn’t know what fields like “name” or “date of birth” actually mean. So, while JWT VCs are simpler and easier to issue, they potentially put more of a burden on verifiers.

JSON-LD based Verifiable Credentials make the opposite trade-offs of JWTs. They are more complicated, harder to construct, and are newer, meaning there is less pre-existing support for them, but are likely the future of Verifiable Credentials. JSON-LD based credentials allow for an issuer to attach semantic meaning to the credentials that make it easy for Verifiers to interpret them and thus make it easier for Verifiers to design business and app logic around these types of credentials. Furthermore, JSON-LD credentials leave the door open for doing cool stuff like Zero-Knowledge Proofs. At Disco, we are big fans of JSON-LD based credentials because they are compatible with the Ethereum standard, EIP712, which allows you to use your Ethereum wallet to issue credentials with Disco!

Now that we have covered the different implementations of the VC standard, we are finally ready to talk about how all of this stuff comes together to solve actual problems for real people. That’s what all this technical wizardry is about at the end of the day, right?

As we work through these phases of a credentials life, let’s imagine a Junior Developer, Alice, who is embarking on her journey into Web3.

The first thing Alice needs to do is get a credential. The credential Alice wants is one from an online Web3 developer bootcamp. Let’s call it DEV3. DEV3 has a web app that teaches Alice important Web3 developer concepts and quizzes her on her knowledge. After a few weeks of studying and practicing, Alice passes the final test with flying colors.

Now, it’s important to note that when Alice logs into the online learning platform, she does so using her Decentralized Identifier, which as we know, is just a fancy public address that Alice manages using her Web3 wallet.

So, the DEV3 app knows Alice’s DID. When Alice completes the course the app creates a Verifiable Credential attesting to Alice’s completion that contains all of her grades for all the modules in the course. This credential is then signed by DEV3’s private key which is associated with their own DID.

On the DEV3 website, Alice sees the credential she has earned displayed to her on screen. Nice! But, what is Alice supposed to do with it?

The next step for Alice is to take custody of her newly issued Verifiable Credential. This is where Disco comes in! Alice is told by DEV3 that she can download her VC where it will sit on her computer like any other file (pretty lame, tbh)  but she can also claim it and store it using Disco. For Alice, this is perfect because she wants to be able to use this credential to take the next step in her developer career in Web3.

Alice clicks “Claim with Disco” and is taken to the Disco web app. She proceeds to connect her wallet (which also connects her DID) to the Disco app. And there it is! The credential is available to save to her private storage in her Disco Data Backpack. Alice has now officially received her first Verifiable Credential!

At this point, Alice wants to use her credential to prove that she is a capable Web3 developer so that she can get a job. The first thing she does is mark her credential as “public” on Disco which adds the credential to her public Disco profile. Because Alice is really into this Web3 stuff she decides to join a DAO whose mission is to build tools for NFT artists. Let’s call this DAO, CreatorDAO.

Alice applies to CreatorDAO using their website where she again connects her wallet. In addition to basic information, CreatorDAO would also like to know if Alice has any Web3 development experience. This is where Alice’s Verifiable Credential from DEV3 really shines! Because Alice connected her wallet (and her DID) to CreatorDAO’s site, CreatorDAO can call Disco’s API to pull Alice’s public profile which contains the Verifiable Credential from DEV3.

It’s important to note that this pattern is specific to Disco. In the Verifiable Credential spec there is another type of disclosure pattern that is outlined. This pattern makes use of something called a Verifiable Presentation (VP). A VP is often used when a user wants to disclose a credential in a peer-to-peer fashion. This would be like if Alice didn’t want to make her credential public on her profile and instead wanted to just disclose the credential privately to CreatorDAO. To do this, CreatorDAO sends a request for disclosure to the app that Alice uses to both manage her credentials but inside of the Verifiable Presentation and signing all of it with her private key and sending it to CreatorDAO’s app. This would allow CreatorDAO to perform the next step, Verification.

The process of verifying a VC involves doing a couple of checks. In Alice’s case, CreatorDAO needs to check if the person disclosing the credential to them is the person that is listed in the subject field of the credential. This is analogous to checking to make sure someone isn’t trying to use someone else’s credential. In cases where DIsco is being used by the user, this is where CreatorDAO compares the DID that is connected to their site to the DID in the credential.

In cases where a Verifiable Presentation is used, CreatorDAO would resolve the signature on the VP to get the DID of who they are currently interacting with and comparing that DID to the DID in the subject field of the VC contained inside of the VP. Verifiable Presentations coming to Disco in the future!

The next check CreatorDAO runs is to make sure that the credential hasn’t been tampered with. They do this by checking a cryptographic hash in the proof section of the VC.

For most cases this is all it takes! However, in some cases CreatorDAO might also want to check to see if the VC has been revoked.

Almost there! This is the final step. CreatorDAO now needs to check if the credential suits their specific organizational needs. What qualifies as validation will be different from verifier to verifier. CreatorDAO for instance doesn’t trust just anyone to be the issuer of a Web3 Developer credential, they only trust a number of organizations they are familiar with. DEV3 is one of those organizations! So, the CreatorDAOs app checks the issuer DID on the credential. If CreatorDAO already knows DEV3’s DID they can simply resolve the DID to the DID Document to check and see if the keys that signed the VC are still valid and if they are then great! But, let’s say CreatorDAO doesn’t already know DEV3’s DID, instead they know DEV3’s domain name, DEV3.xyz. Using Disco, CreatorDAO simply calls the Disco API and feeds it the issuer DID from Alice’s credential. This returns a profile that is verifiably connected to DEV3.xyz via another verifiable credential. Voila! CreatorDAO is able to confirm who the issuer of Alice’s VC is without needing to contact or integrate with the issuer directly!

CreatorDAO then performs a couple other validation checks such as checking to make sure the credential was issued within the past 6 months and that it matches the Course Completion VC schema as well as running some check on the grades contained in the VC to make sure that Alice was indeed a top tier student!

Of course Alice and her VC pass all the checks which happen nearly instantaneously in the background as soon as she submits her application. This means that she is immediately accepted! No waiting for a review by a human, no asking her to supply any other documents, no need for complex and costly integrations between CreatorDAO and DEV3, and no ability for DEV3 to prevent Alice from using her credential. ** **

On top of all of the above concepts, there are a couple more things being worked on that you should be excited about. One of the ideas is already getting broad adoption and is something that we plan to implement at Disco in the (hopefully near) future. That is the concept of Zero-Knowledge Proofs which we’ll cover briefly in a second. The next is a really interesting field of research that is great brain fodder to keep you up at night!

Zero-Knowledge proofs, put simply, allow Alice to prove a fact about herself without disclosing all the data that makes up that proof. The classic example is of someone proving they are over a certain age. Let’s say Alice has a Verifiable Credential from the hospital at which she was born that attests to her birthday. And let’s say that CreatorDAO only wants to accept people that are over 16 because of certain labor laws. Alice could use her VC to prove her birthdate and subsequently her age. But, what if Alice just wanted to prove she was over 16 without disclosing her actual age? This is where she could use a Zero-Knowledge Proof or ZKP for short. You can think of a ZKP as the code equivalent of  a machine inside a box that two parties can’t see inside of but can trust whatever it outputs. This means that Alice can put her VC that contains her birthdate into the ZKP and it will spit out a yes or no answer to whether or not she is above 16!

Implementing a Zero-Knowledge Proof scheme with Verifiable Credentials requires the VC to be built in a certain way. This is where the type of VC you use matters. JWT based VCs are not conducive to using ZKPs but JSON-LD VCs are. Because of the way JSON-LD VCs are structured and because of their semantic clarity, we can use a special signature scheme (called BBS+) to prove things about specific fields (like age or grade or ranking) inside of the Verifiable Credential. The process of allowing a user to prove just certain things about themself is called Selective Disclosure. While, Selective Disclosure can be essentially accomplished by breaking all the data a user would get as a single VC into a number of VCs the other way is to use ZKPs. The trade off is that turning a VC that would normally have 5 different fields into 5 different VCs puts a burden on issuers and instead using a ZKP moves that burden to verifiers. It is generally thought that getting verifiers to support ZKPs will be a much more scalable and manageable strategy in the long run.

For our final topic, let’s talk about a very clever (but largely theoretical) implementation of VCs and ZKPs. Non-reusable proofs aim to mitigate the ability for verifiers to participate in Surveillance Capitalism which is the business model of collecting and selling user data without a user’s knowledge or informed consent.

The way they work is like this: imagine a Zero-Knowledge Proof that didn’t just prove one thing (as in the case of proving Alice is above a certain age) but instead proved one of two things. Those two things could be that either Alice is over 16 or that Alice knows CreatorDAO’s private key. This is clever because CreatorDAO knows that Alice doesn’t have their private key but nobody else knows that for certain. Now let’s imagine CreatorDAO was interested in selling their user data (like Alice’s age for instance) to a data aggregator who was compiling a database of the ages of Web3 users and their Ethereum addresses to then sell to advertisers. When the data aggregator received the proof that Alice supplied to CreatorDAO to prove that she was over 16 (using a non-reusable proof) the aggregator could not be certain that Alice is indeed over 16. This is because CreatorDAO does know their own private key, and remember, the proof proves one of two things: either the creator of the proof is over 16 or they know CreatorDAOs private key. All of this means that the data aggregator has no way of knowing if CreatorDAO is selling them fraudulently created data which they would have the incentive to do since they are getting paid for it! Crazy, right?** **

From Decentralized Identifiers to Verifiable Credentials to Zero-Knowledge Proofs, Disco aims to make these things practical and useful. We truly believe in the promise of these technologies and their potential to solve the Web3’s, the internet’s and in some cases, even society’s toughest problems. User autonomy and consent is of paramount importance if we want a more equitable, Web3 enabled future. But alas, the dance never ends and there is still more to learn. Going forward we will begin to dive deeper into adjacent topics and work our way through example use cases of how all of this stuff comes together to solve problems for real people and organizations. Stay tuned!

If you are as excited as we are about all of these things make sure to follow us on the bird app @discoxyz and also check us out at www.disco.xyz!

Jonny Howle

Co-Founder / Head of Strategy

@jonnyhowle

Please use ask@disco.xyz for any comments, or register for a 1:1 feedback session here.

Hanging in there? We’ve covered a lot in the past two posts. But don’t worry, we’re in the final stretch. In this installment of our series on Verifiable Credentials we’ll talk about the different implementations of credentials, the lifecycle of a credentials and finally, we’ll cover some of the sexy (to nerds like us, anyway) cryptographic techniques we can use with VCs, such as zero-knowledge proofs. Are you ready? Ok, let’s go!

Now, it would be great if Verifiable Credentials were just Verifiable Credentials and that was the end of it, but alas, the nuance continues. The Verifiable Credential spec from the W3C leaves some of the implementation details up to interpretation, meaning that while VCs are a standard, there is still some ongoing experimentation. There are 2 main types of Verifiable Credentials: ones that are based on JSON Web Signatures and ones that are based on Linked Data Proofs. The ones based on JSON Web Signatures come in the form of something called a JSON Web Token, or JWT for short. And the others you’ll often see referred to as JSON-LD.

JWT based VCs are simpler and based on an older, more widely adopted standard. This makes JWT based VCs easier to work with as there exists more developer tooling. However, because of this simplicity, JWT based VCs can’t do some of the more fancy things we will talk about. Additionally, JWT based VCs lack semantic clarity. What that means is that when a Verifier’s web app is attempting to interpret a credential that a user is disclosing to it, the web app doesn’t know what fields like “name” or “date of birth” actually mean. So, while JWT VCs are simpler and easier to issue, they potentially put more of a burden on verifiers.

JSON-LD based Verifiable Credentials make the opposite trade-offs of JWTs. They are more complicated, harder to construct, and are newer, meaning there is less pre-existing support for them, but are likely the future of Verifiable Credentials. JSON-LD based credentials allow for an issuer to attach semantic meaning to the credentials that make it easy for Verifiers to interpret them and thus make it easier for Verifiers to design business and app logic around these types of credentials. Furthermore, JSON-LD credentials leave the door open for doing cool stuff like Zero-Knowledge Proofs. At Disco, we are big fans of JSON-LD based credentials because they are compatible with the Ethereum standard, EIP712, which allows you to use your Ethereum wallet to issue credentials with Disco!

Now that we have covered the different implementations of the VC standard, we are finally ready to talk about how all of this stuff comes together to solve actual problems for real people. That’s what all this technical wizardry is about at the end of the day, right?

As we work through these phases of a credentials life, let’s imagine a Junior Developer, Alice, who is embarking on her journey into Web3.

The first thing Alice needs to do is get a credential. The credential Alice wants is one from an online Web3 developer bootcamp. Let’s call it DEV3. DEV3 has a web app that teaches Alice important Web3 developer concepts and quizzes her on her knowledge. After a few weeks of studying and practicing, Alice passes the final test with flying colors.

Now, it’s important to note that when Alice logs into the online learning platform, she does so using her Decentralized Identifier, which as we know, is just a fancy public address that Alice manages using her Web3 wallet.

So, the DEV3 app knows Alice’s DID. When Alice completes the course the app creates a Verifiable Credential attesting to Alice’s completion that contains all of her grades for all the modules in the course. This credential is then signed by DEV3’s private key which is associated with their own DID.

On the DEV3 website, Alice sees the credential she has earned displayed to her on screen. Nice! But, what is Alice supposed to do with it?

The next step for Alice is to take custody of her newly issued Verifiable Credential. This is where Disco comes in! Alice is told by DEV3 that she can download her VC where it will sit on her computer like any other file (pretty lame, tbh)  but she can also claim it and store it using Disco. For Alice, this is perfect because she wants to be able to use this credential to take the next step in her developer career in Web3.

Alice clicks “Claim with Disco” and is taken to the Disco web app. She proceeds to connect her wallet (which also connects her DID) to the Disco app. And there it is! The credential is available to save to her private storage in her Disco Data Backpack. Alice has now officially received her first Verifiable Credential!

At this point, Alice wants to use her credential to prove that she is a capable Web3 developer so that she can get a job. The first thing she does is mark her credential as “public” on Disco which adds the credential to her public Disco profile. Because Alice is really into this Web3 stuff she decides to join a DAO whose mission is to build tools for NFT artists. Let’s call this DAO, CreatorDAO.

Alice applies to CreatorDAO using their website where she again connects her wallet. In addition to basic information, CreatorDAO would also like to know if Alice has any Web3 development experience. This is where Alice’s Verifiable Credential from DEV3 really shines! Because Alice connected her wallet (and her DID) to CreatorDAO’s site, CreatorDAO can call Disco’s API to pull Alice’s public profile which contains the Verifiable Credential from DEV3.

It’s important to note that this pattern is specific to Disco. In the Verifiable Credential spec there is another type of disclosure pattern that is outlined. This pattern makes use of something called a Verifiable Presentation (VP). A VP is often used when a user wants to disclose a credential in a peer-to-peer fashion. This would be like if Alice didn’t want to make her credential public on her profile and instead wanted to just disclose the credential privately to CreatorDAO. To do this, CreatorDAO sends a request for disclosure to the app that Alice uses to both manage her credentials but inside of the Verifiable Presentation and signing all of it with her private key and sending it to CreatorDAO’s app. This would allow CreatorDAO to perform the next step, Verification.

The process of verifying a VC involves doing a couple of checks. In Alice’s case, CreatorDAO needs to check if the person disclosing the credential to them is the person that is listed in the subject field of the credential. This is analogous to checking to make sure someone isn’t trying to use someone else’s credential. In cases where DIsco is being used by the user, this is where CreatorDAO compares the DID that is connected to their site to the DID in the credential.

In cases where a Verifiable Presentation is used, CreatorDAO would resolve the signature on the VP to get the DID of who they are currently interacting with and comparing that DID to the DID in the subject field of the VC contained inside of the VP. Verifiable Presentations coming to Disco in the future!

The next check CreatorDAO runs is to make sure that the credential hasn’t been tampered with. They do this by checking a cryptographic hash in the proof section of the VC.

For most cases this is all it takes! However, in some cases CreatorDAO might also want to check to see if the VC has been revoked.

Almost there! This is the final step. CreatorDAO now needs to check if the credential suits their specific organizational needs. What qualifies as validation will be different from verifier to verifier. CreatorDAO for instance doesn’t trust just anyone to be the issuer of a Web3 Developer credential, they only trust a number of organizations they are familiar with. DEV3 is one of those organizations! So, the CreatorDAOs app checks the issuer DID on the credential. If CreatorDAO already knows DEV3’s DID they can simply resolve the DID to the DID Document to check and see if the keys that signed the VC are still valid and if they are then great! But, let’s say CreatorDAO doesn’t already know DEV3’s DID, instead they know DEV3’s domain name, DEV3.xyz. Using Disco, CreatorDAO simply calls the Disco API and feeds it the issuer DID from Alice’s credential. This returns a profile that is verifiably connected to DEV3.xyz via another verifiable credential. Voila! CreatorDAO is able to confirm who the issuer of Alice’s VC is without needing to contact or integrate with the issuer directly!

CreatorDAO then performs a couple other validation checks such as checking to make sure the credential was issued within the past 6 months and that it matches the Course Completion VC schema as well as running some check on the grades contained in the VC to make sure that Alice was indeed a top tier student!

Of course Alice and her VC pass all the checks which happen nearly instantaneously in the background as soon as she submits her application. This means that she is immediately accepted! No waiting for a review by a human, no asking her to supply any other documents, no need for complex and costly integrations between CreatorDAO and DEV3, and no ability for DEV3 to prevent Alice from using her credential. ** **

On top of all of the above concepts, there are a couple more things being worked on that you should be excited about. One of the ideas is already getting broad adoption and is something that we plan to implement at Disco in the (hopefully near) future. That is the concept of Zero-Knowledge Proofs which we’ll cover briefly in a second. The next is a really interesting field of research that is great brain fodder to keep you up at night!

Zero-Knowledge proofs, put simply, allow Alice to prove a fact about herself without disclosing all the data that makes up that proof. The classic example is of someone proving they are over a certain age. Let’s say Alice has a Verifiable Credential from the hospital at which she was born that attests to her birthday. And let’s say that CreatorDAO only wants to accept people that are over 16 because of certain labor laws. Alice could use her VC to prove her birthdate and subsequently her age. But, what if Alice just wanted to prove she was over 16 without disclosing her actual age? This is where she could use a Zero-Knowledge Proof or ZKP for short. You can think of a ZKP as the code equivalent of  a machine inside a box that two parties can’t see inside of but can trust whatever it outputs. This means that Alice can put her VC that contains her birthdate into the ZKP and it will spit out a yes or no answer to whether or not she is above 16!

Implementing a Zero-Knowledge Proof scheme with Verifiable Credentials requires the VC to be built in a certain way. This is where the type of VC you use matters. JWT based VCs are not conducive to using ZKPs but JSON-LD VCs are. Because of the way JSON-LD VCs are structured and because of their semantic clarity, we can use a special signature scheme (called BBS+) to prove things about specific fields (like age or grade or ranking) inside of the Verifiable Credential. The process of allowing a user to prove just certain things about themself is called Selective Disclosure. While, Selective Disclosure can be essentially accomplished by breaking all the data a user would get as a single VC into a number of VCs the other way is to use ZKPs. The trade off is that turning a VC that would normally have 5 different fields into 5 different VCs puts a burden on issuers and instead using a ZKP moves that burden to verifiers. It is generally thought that getting verifiers to support ZKPs will be a much more scalable and manageable strategy in the long run.

For our final topic, let’s talk about a very clever (but largely theoretical) implementation of VCs and ZKPs. Non-reusable proofs aim to mitigate the ability for verifiers to participate in Surveillance Capitalism which is the business model of collecting and selling user data without a user’s knowledge or informed consent.

The way they work is like this: imagine a Zero-Knowledge Proof that didn’t just prove one thing (as in the case of proving Alice is above a certain age) but instead proved one of two things. Those two things could be that either Alice is over 16 or that Alice knows CreatorDAO’s private key. This is clever because CreatorDAO knows that Alice doesn’t have their private key but nobody else knows that for certain. Now let’s imagine CreatorDAO was interested in selling their user data (like Alice’s age for instance) to a data aggregator who was compiling a database of the ages of Web3 users and their Ethereum addresses to then sell to advertisers. When the data aggregator received the proof that Alice supplied to CreatorDAO to prove that she was over 16 (using a non-reusable proof) the aggregator could not be certain that Alice is indeed over 16. This is because CreatorDAO does know their own private key, and remember, the proof proves one of two things: either the creator of the proof is over 16 or they know CreatorDAOs private key. All of this means that the data aggregator has no way of knowing if CreatorDAO is selling them fraudulently created data which they would have the incentive to do since they are getting paid for it! Crazy, right?** **

From Decentralized Identifiers to Verifiable Credentials to Zero-Knowledge Proofs, Disco aims to make these things practical and useful. We truly believe in the promise of these technologies and their potential to solve the Web3’s, the internet’s and in some cases, even society’s toughest problems. User autonomy and consent is of paramount importance if we want a more equitable, Web3 enabled future. But alas, the dance never ends and there is still more to learn. Going forward we will begin to dive deeper into adjacent topics and work our way through example use cases of how all of this stuff comes together to solve problems for real people and organizations. Stay tuned!

If you are as excited as we are about all of these things make sure to follow us on the bird app @discoxyz and also check us out at www.disco.xyz!

Jonny Howle

Co-Founder / Head of Strategy

@jonnyhowle

Please use ask@disco.xyz for any comments, or register for a 1:1 feedback session here.