- Hyperledger Fabric - KFS
- Posts
- How to integrate Hyperledger Fabric and Decentralized identity
How to integrate Hyperledger Fabric and Decentralized identity
Hi There!
For the last few years, I have developed projects in Aries Framework Javascript(now Credo TS) and Hyperledger Fabric.
Most of the projects have been separated into either Hyperledger Fabric or Aries.
But lately, I’m developing a project where I had to integrate them.
To know how we need to know the role of each technology.
Hyperledger Fabric is useful to maintain a permissioned ledger across multiple organizations.
But what data related to Decentralized identity needs to be shared?
Trust triangle
First, let’s understand the trust triangle

Trust triangle
So, we have three components:
Holder
Issuer
Verifier
The issuer issues a credential to the identity holder.
The verifier asks the holder for a credential, and then the verifier decides whether the issuer is trustworthy or not.
That’s where the concept of Anoncreds and the integration with Fabric come in.
Anoncreds
Anoncreds is a specification to create and manage credentials in a privacy-preserving manner. The idea was to replace Indy in Hyperledger Aries and provide a ledger-agnostic mechanism to store schemas, revocation and authorized issuers.
The following picture represents the data model related to Anoncreds.

Anoncreds model
As you can see, the data is separated for each actor.
The Holder stores the Verifiable Credential locally in their wallet; the Issuer issues the credentials.
We have the Anoncred Presentation for the Verifier, which is equivalent to a Verifiable Presentation.
A verifiable credential is usually a JSON with data related to the credential; if the government is issuing a driver's license credential to you, then the data will be:
First name and last name
Identification Number
This credential is signed by the issuer and issued to a specific Decentralized Identifier(DID), which is stored in your wallet.
Decentralized identifiers
A DID is a representation that contains the public key associated with some metadata. This is an example
did:key:zDnaerDaTF5BXEavCrfRZEk316dpbLsfPDZ3WJ5hRTPFU2169
The format of a DID is:
did:<method>:<identifier>
In the example above, the DID method is key
, a self-contained format to embed the public key in the DID.
The issuer and holder have a DID associated since they are needed to issue and present VCs.
When a credential is issued, the DID is embedded in the credential and signed by the issuer.
Then, the Holder creates and signs the Verifiable Presentation to send to the Verifier. This way, we can detect:
Data tampering of the credential
If the presentation is signed by the original Holder
Integration with Fabric
We need a common Verifiable Data Registry (VDR) to store:
Schemas
Revocation entries
Authorized Issuers
There are multiple solutions to this:
But if we are going to develop a PoC, or we want to understand the system, we can store the data related to the VDR wherever we want, which can be:
Hyperledger Fabric
Public blockchain (Ethereum, Polygon)
Even a database! But is only recommended for testing
Luckily, with Credo (Aries Framework Javascript), we can implement our own VDR easily using Anoncreds.
This is the interface we need to implement in each of the components:

A schema is the representation of the data to be used when issuing a VC.
A Credential Definition is the association between an Issuer ID (the DID) and the schema.
Then, we have the revocation registry, which is helpful for credentials we need to revoke before the expiration is met.
So, what’s the next step?
We would need to create a chaincode in Fabric to store this data.
This is an example of a chaincode hosted on Gist:
So, the final figure would be like this after integrating it with Fabric:

Conclusion
In conclusion, integrating Aries Framework Javascript (now Credo TS) with Hyperledger Fabric represents a significant step forward in the practical application of decentralized identities and permissioned ledgers.
By combining the strengths of both platforms, this integration offers a versatile, secure, and privacy-preserving framework for managing digital identities.
I hope you enjoyed this post!
If you liked this content, please send feedback to me on Linkedin for the following weeks!
I’d love to hear your ideas! https://www.linkedin.com/in/david-viejo.
— David