There are many kinds of identity, but one of the most crucial and valuable – especially for financial applications – is the concept of an identity that includes credentials.

DeFi and Web3 today are in the experimentation phase. So far dApps have made do without real-world credentials, but that time is coming to an end. More and more developers are realizing that mature applications often need things like “proof of human”, AML/KYC, and other kinds of real-world qualifications, permits, and licenses. 

Decentralized applications need to be able to write smart contract logic around verified answers to questions like:

• Is this user a unique person?
• Does this user meet an age requirement?
• Where does this user live?
• Is this user qualified to hold the assets traded here?
  ‍

Existing blockchain solutions to this problem create unacceptable compromises, whether loss of privacy, or giving up the frictionless interoperability that make Web3 great.

Radix is proposing a new system for credentials on the Radix Network that can finally provide true “digital ID cards” for Web3 and DeFi without compromises.

This article provides an overview of what’s at stake with credential-based identity, existing solutions, and a description of the Radix solution, enabled by the unique identity features the Radix Network already offers.

What are “credentials”?

The common feature of all the questions above is that a dApp can’t simply trust an answer provided by the user. A user can easily lie about things like their uniqueness (often called a Sybil attack), their age, where they live, and if they’re qualified to hold certain assets.

Knowing that any of those things are true requires some sort of verification that can only be done in the real world. Depending on the situation, that verification could be anything from an SMS code to a careful check of a government-issued passport.

Some applications might choose to do that real-world verification themselves, but that quickly becomes a major burden. So typically applications choose to trust a third party of some kind to correctly verify some real-world proof and provide a simple answer to the question the application is trying to answer (like “where does this user live?”).

This means that any sort of credential system is a relationship between three parties:

• A user
• The application the user wants to use
• A credential issuer that specializes in checking real-world proof of things about users
  ‍

Here’s an example with user Alice, an application CanaDEX that Alice wants to use, and a credential issuer KYC Haus:

‍

First, the application needs to decide which issuers it believes do the appropriate checks for the questions they want to ask about users. In our example, CanaDEX chooses to trust KYC Haus:

Now Alice needs to provide the right proof to KYC Haus – her passport, which KYC Haus verifies is correct and valid, meaning it can answer questions about Alice from that passport information.

Finally, CanaDEX can get what it needs. Alice can identify herself, and KYC Haus can (with Alice’s permission of course) tell CanaDEX that she lives in Canada.

That’s the basic concept of all credential-based identity.

In practice today, you sometimes have things like ID cards that offer reusable credentials. For example, bars can easily check that my driver’s license (issued by the state of Texas) is valid and trust that I’m over 21 without doing their own check on my birth certificate.

But very often you have to do checks over and over with individual businesses, who contract with verification vendors specifically for their app. Think about how today you do a separate AML/KYC check with every crypto exchange you sign up for.

A better form of credentials for the digital world is needed – one that is highly reusable while ensuring the user is in control of who they share their private data with.

Users need real digital “ID cards” that Web3 and DeFi applications can easily check and rely on.

W3C’s DID and VC Concept

Enter the W3C – the governance body in charge of standards on the world wide web.

Several years ago, the W3C began working on a pair of standards called DIDs (decentralized identities) and VCs (verifiable credentials). Together, the goal of those standards is to create a basic concept that would allow individual users to directly provide digital credential data to applications, like this:

The goal is that the user should always be in control of choosing what they want to share with each application.

The W3C’s DIDs and VCs provide the basic standards and cryptographic mechanisms that can give users that control while remembering the fundamental nature of credentials: each application needs to make its own decisions about the credential issuers it trusts, and needs to know that credentials come from that issuer.

It works roughly like this:

In short, issuers create DIDs and VCs, and then users can use those DIDs and VCs to prove to applications two things: who they are, and that the credentials they provide to the application came from a given issuer without modification. In more detail:

When a user does a verification with an issuer, the issuer creates a DID for that user – basically a special ID number, where Alice holds a cryptographic key that means only she can prove she is the owner of that ID number. The issuer also produces one or more VCs. The VC is a special kind of file holding the actual data that applications may need. That file has some cryptographic signatures that mean that anybody can see exactly who created the VC, and that it hasn’t been tampered with.

That provides the basic mechanism to allow Alice herself to provide two things directly to the application:

• A cryptographic proof that Alice is the owner of the DID - telling the application “Hi, I’m Alice”
• A VC that the application can verify came from KYC Haus and is valid for Alice’s DID - telling the application “KYC Haus says I am a Canadian”

‍

The DID/VC standards are a clever use of bit of cryptography, and they put the user in full control of credential sharing! But the W3C standards alone are nowhere close to the end of the story. They say nothing about how you build a functional system, leaving lots of crucial unanswered questions, like:

• What is the DID registration mechanism, letting users prove their ownership?
• How does a VC get from the issuer to the application with the user’s permission?
• Where are VCs actually stored and managed?
• What does an application look at to ensure that a given VC is still valid (it hasn’t expired or been revoked by the issuer)?
  ‍

The Problems with Early DID/VC Implementations

The blockchain world has been struggling for some time with how to apply the basic DID/VC concept in practice for dApps. Maybe the most difficult question to answer is this: Where exactly does the issuer issue the VCs and how does an application check them?

Today’s proposed approaches roughly fall into two categories, which I call the off-ledger approach, and the on-ledger approach.

The off-ledger approach is the “traditional” way of handling credential data. Issuers would provide VC data directly to a traditional off-ledger system that can verify the correctness of that VC. Issuers then provide a mechanism for a user to tell them “yes, it’s okay for you to share this VC data with Application X”.

Off-ledger VC/DID systems are used by a number of companies offering verification services, like Evernym or Circle's Verite.

If you’re building a traditional Web2-style system, this works just fine. But there’s a fatal flaw for Web3:

Smart contracts have no natural way of knowing if a user has the right credentials for access. That’s because there’s nothing on-ledger (on the blockchain) that the smart contract logic is able to check.

The dApp backend system could perhaps push messages to the smart contract, oracle-style, but that’s not good enough for Web3 or DeFi. Smart contracts thrive on the ability to “atomically compose” actions right within a single transaction. If a smart contract can’t verify user access within a transaction atomically, you introduce a huge amount of friction that kills the interoperability that DeFi thrives on.

The on-ledger approach tries to fix the interoperability issue. In this approach, the issuer issues VC data right onto the blockchain itself. In fact the version of the concept gathering the most excitement is to tokenize the credential by making it an NFT. The data would be loaded right into the NFT smart contract along with the registry of who owns what NFT. This means that smart contracts can check VC data atomically, and credentials could even (where appropriate) be transferable (or, alternatively, “soul bound”).

The on-ledger approach is the one described by the proposed ERC-725 standard on Ethereum, and the related ERC-735.

This approach has a different fatal flaw - perhaps an even worse one:

If VC data is on the blockchain for smart contracts to examine, then anyone can see that data since the blockchain is open. This of course is a privacy nightmare if anyone can see that a given user is, say, a 15 year old girl living in a certain town in Romania.

Of course there are proposals to encrypt this data in various ways, enabling more selective disclosure. But this only delays the inevitable. Once encrypted data is published publicly, the clock starts ticking on the encryption being broken (or brute forced) and the data becoming revealed. Even if it were 10 years down the road, nobody wants their highly sensitive personal data to end up in the open.

Clearly a very different approach is taken to fulfill the promise of the DID/VC concept for use in Web3.

The Radix DID Badge System

Radix is proposing a unique implementation of the W3C’s DID and VC standards, making use of the Radix Network’s native badge-based auth system and the Radix Wallet. This implementation keeps sensitive VC data off-ledger, while still enabling components (Radix-style smart contracts) to use credentials for atomic, transaction-by-transaction access.

The Radix system starts at issuance, with a very different mechanism than either of the existing approaches described above. On Radix, when an issuer has checked some real-world proof and is ready to create DIDs and VCs, it does so in two parts: A DID Badge, and the VC Data associated with that DID.

‍

The simplest way to think about the system is that it splits up the two things the user needs to prove to the application.

• The VC Data is used to prove “KYC Haus says that I (Alice) am a Canadian”.
• The DID Badge is used to prove “I am Alice”
  ‍

Here’s the breakdown in more detail.

VC Data on Radix

The VC Data itself is quite simple. It is just the special cryptographically-secured file described in the original W3C standard. Anyone that examines that file can verify who issued the VC, and that the data hasn’t been tampered with. VCs are always issued for a given DID, representing that user.

What’s different in the Radix proposal is how VC Data is managed and shared. In this system, the Radix Wallet directly manages the VC Data that is issued. This keeps it off-ledger, for privacy, and lets users directly control, right in their wallet, what dApps they share it with. More on that a little later.

DID Badges on Radix

The DID Badge is a very new way of approaching DIDs. On Radix, the DID isn’t just an abstract idea; it is an actual asset, a non-fungible token. On Radix, tokens aren’t smart contracts, and so the DID Badge automatically inherits all of the security, transparency, and configurability of native Radix assets.

You can think of the DID Badge as a real “ID card” that you hold in your wallet, created by the issuer. You’ll see shortly how that enables nice on-ledger use with smart contracts by simply “presenting” the badge to prove you own it.

Each DID Badge also includes some data set by the issuer. Think of it like extra information printed on a physical ID card (except that the printing can be easily updated by the issuer later). The most important data on each DID Badge is a reference to the VC Data that the issuer has created for that user, and if that VC is still valid at this moment.

It’s worth being clear about something here: the VC Data itself (ie. the private stuff) is not set on the DID Badge. Anybody looking at a user’s DID Badge will only know that a given piece of VC Data exists and is currently valid. For example, Alice’s DID Badge might effectively say: “KYC Haus issued a VC for this DID that is about ‘country of residence’. That VC is currently still valid.”

Each issuer only issues one DID Badge to each unique user. Multiple VCs can refer to that single DID, and the DID Badge can reference and describe the validity of those multiple VCs.

Now let’s see how these DID Badges and VCs are used with applications.

Onboarding Credentialed Users

A key to the privacy of the Radix DID Badge system is a one-time onboarding process with each dApp. The purpose of this onboarding is to check (off-ledger) that the user has had the right checks done by a trusted issuer, and then inform the dApp’s smart contract that the user with the corresponding DID Badge is a good user – if the required VC is still valid at the time that they use the smart contract.

This is a really important step. It splits the off-ledger VC Data checking from the on-ledger access.

The way it works in practice is that the dApp can make a request directly to the wallet for the VC data it needs - probably when the user first logs in. The dApp is aware of what VCs it can ask for because it can see the user’s Account holds a DID Badge (from an issuer the dApp trusts) and that badge references a VC of type it needs from that issuer.

So for example:

Alice might log in to CanaDEX and get a request for a KYC Haus VC for “country of residence”. Alice approves sharing that data in her Radix Wallet, and CanaDEX’s backend system quickly verifies that the VC is good and that Alice is a resident of Canada.

Then the backend system sends a one-time message to its smart contract telling it that it may accept Alice’s DID Badge for access – if the smart contract can see that the VC is still valid when Alice tries to use the badge in a transaction.

Using DID Badges in Transactions

So let’s look at what using the DID Badge in a transaction would look like:

‍

Proving that you own a DID on Radix isn’t an abstract cryptographic notion. It is a very direct “presenting” of the DID Badge NFT to the application you want to use, supported by the Radix Network’s built-in features. It’s like holding up your ID card to a security guard at the door of a business.

This is where Radix’s native badge-based auth system comes into play. Transactions on Radix can present a proof that the user owns any badge (any asset in fact).

It’s easy for developers to configure their smart contracts to require proof of any given badge (or combination of badges) to allow use of a given feature. Checking the badges is done by the Radix system itself, not smart contract logic, so it’s both simpler and more reliable.

When a user presents a DID Badge in a transaction, the component can ensure that only DIDs on the “good user” list are allowed – and it can check that the VC it cares about is still valid… crucially without having to examine the privacy-critical VC data directly.

That’s how the system can provide atomic credentialled access, without exposing VC data on the network.

How does this feel to users? Like this:

In the Radix Wallet, the screen describing the transaction to the user shows a “presenting” section with the badge being used. That’s it.

A Little More about Current Validity Checking

Up to this point, this article has been saying that the DID Badge itself says if a given VC is currently valid. The idea would be that the issuer can either specify an expiration date for the VC, or if there’s a problem, it can simply update the DID Badge to say “this VC exists, but it’s no longer valid”.

While that approach works in many cases, in some circumstances an issuer may wish to handle validity checks in a different way, and so a second approach is also part of the proposed Radix system.

An issuer may choose to “print” the DID badge to say that checking the validity of a given VC requires a call to a specified registry smart contract. That smart contract, created by the issuer, can be called to look up the current validity of a given DID and VC.

Why offer this option? Two reasons: An issuer might want the convenience of a bulk update of a large amount of validity data for many users, and an issuer might want to charge a fee to smart contracts that want to look up the validity of VCs within transactions.

The Radix system will include a standard method interface for registry smart contracts, so that components can easily do these look-ups for DID Badges that require it, providing the fee at the same time if required.

VC Issuance and Storage with idOS

There’s one last extension to the Radix system worth talking about. Up to this point, this article has been saying that the Radix Wallet receives VC Data from the issuer so it can provide it directly to dApp systems upon request. The idOS network provides a very interesting potential improvement.

idOS is a decentralized system created specifically to provide cross-platform use of identity data – essentially VCs. The concept is that an issuer can issue credentials for a given user (DID) directly into the idOS platform. That done, only the user themselves can access that VC data (or others that the user provides permission to). This means that users and applications on networks that idOS integrates to can make use of this VC Data, even if it was originally intended for use on a different network.

With idOS, it may be possible to simplify the process of getting new credentials from issuers, and storing those VCs for later use by the Radix Wallet.

‍

In short, the user’s Radix Wallet would sign on to the idOS network and view any VCs issued for that user, by any issuer. When a dApp on Radix needs a given VC, it would still request it from the user’s Radix Wallet – just as described above. But behind the scenes, the Radix Wallet would fetch the VC data from idOS before providing it to the dApp (if the user gives permission in the wallet to do so). If that VC is referenced by a DID Badge the user holds, then the Radix Wallet would know it can present it in a transaction on the Radix Network.

This would not change the fundamental Radix DID/VC system approach, but offers an interesting option to consider as the Radix Wallet is updated to support use of DID Badges.

More about the potential integration of Radix into idOS is coming soon.

Details for Developer Community Feedback

If you’re a developer with a dApp that could use real-world credentials for access, the Radix team is interested in hearing from you. Let them know what you think of the Radix DID Badge concept in the official Radix developer channels. And keep an eye out for a “request for feedback” post on the DID/VC credentials that will provide finer detail on a proposed standard for the DID Badge metadata/NFdata and registry component method interface that you would integrate to.