Chapter 5: The Old Way — Aries, Indy, and DIDComm
What you'll learn:
- Why the first generation of SSI was built on blockchain
- The components of the Hyperledger stack: Indy, Aries, ACA-Py, DIDComm, AnonCreds
- What this stack actually achieved — and what it did well
- Where adoption broke down and why
- The honest verdict: a pioneering effort that revealed what the next generation needed to fix
The moment that created this stack
In 2017, two things happened at roughly the same time.
The first was the publication of Christopher Allen's "The Path to Self-Sovereign Identity" — a widely-read essay that articulated the ten principles of SSI and gave the movement a name and a philosophy. The second was the explosion of blockchain technology as a general-purpose trust infrastructure. Bitcoin had proven that a distributed ledger could record facts without a central authority. The natural question was: could the same mechanism make digital identity decentralised?
The answer, from the developers who became Hyperledger, was yes — and the result was a serious, well-funded, earnestly built attempt to do exactly that.
The stack that emerged from this period has a specific name: the Hyperledger SSI stack. Understanding it matters not because you will build with it, but because it shaped every design decision in what came next.
The components
The Hyperledger SSI stack is composed of five interlocking pieces. They were designed together and depend on each other.
Hyperledger Indy
Indy is a permissioned blockchain ledger built specifically for identity. Unlike Bitcoin or Ethereum — which are public and allow anyone to write to them — Indy is operated by a defined set of known nodes (the "Sovrin Network" being the most prominent public deployment). Writing to Indy requires permission. Reading is free.
The ledger stores four types of data:
- DIDs and DID documents — the public keys of issuers and holders
- Credential schemas — the fields a given credential type will contain
- Credential definitions — the issuer-specific signing keys for a schema
- Revocation registries — cryptographic accumulators that allow revocation without revealing which credential was revoked
Hyperledger Aries
Aries is not a ledger. It is a protocol framework — a specification for how identity agents communicate with each other. Aries defines the "protocols" for every step of a credential lifecycle: how two agents establish a peer-to-peer connection, how an issuer offers and delivers a credential, how a verifier requests a proof, and how a holder responds.
Aries was designed to be ledger-agnostic in principle (any DID method could theoretically work), but in practice it was built for and with Indy.
ACA-Py
ACA-Py (Aries Cloud Agent — Python) is the most widely used reference implementation. It is a server-side agent that speaks DIDComm and implements the Aries protocols. A bank wanting to issue credentials would run an ACA-Py instance. A government verifier would run another. Each acts as a DIDComm-capable agent.
AnonCreds
AnonCreds (Anonymous Credentials) is the credential format native to Indy and Aries. It is based on zero-knowledge proofs — a form of cryptography that allows a prover to demonstrate a fact without revealing the underlying data.
AnonCreds has a genuinely impressive privacy model:
- A holder can prove they hold a valid credential without revealing the credential's serial number (unlinkability)
- A holder can prove they are over 18 without revealing their date of birth (predicate proofs)
- Revocation checks can be done without the issuer learning who is being checked
These are real privacy properties that took significant cryptographic work to achieve.
DIDComm
DIDComm is the transport protocol — the "how messages travel between agents" layer. Where HTTPS is a stateless request-response protocol, DIDComm is a stateful, encrypted, peer-to-peer messaging protocol. Agents first establish a connection (a mutual exchange of DID documents and encryption keys), then send encrypted messages to each other using those keys.
Every step of the credential lifecycle — offering, issuing, requesting a proof, presenting a proof — is a DIDComm message.
The Mediator
Here is where the complexity starts to surface. DIDComm messages are sent from agent to agent. A server-side agent (like a bank's ACA-Py instance) has a stable HTTPS endpoint and can receive messages directly. A mobile wallet does not. It may be offline. It may be behind a NAT. It does not have a stable address.
The solution is a mediator: a cloud service that receives DIDComm messages on behalf of a mobile agent and holds them until the agent comes online to pick them up. Every DIDComm-based mobile wallet requires a mediator to function. The mediator is a piece of infrastructure that someone must operate.
What the stack achieved
It would be unfair — and inaccurate — to dismiss the Hyperledger stack as a failure. It achieved real things.
It proved the model. The first working demonstrations of the issuer-holder-verifier triangle, of selective disclosure in a real credential, and of a digital wallet presenting proof of identity without revealing unnecessary data — all of these were built on Aries and Indy. The model worked. The technology demonstrated that SSI was not just a philosophy but a buildable system.
It built a community. The Hyperledger community — developers, standards contributors, government officials — created the intellectual infrastructure that the next generation inherited. Most of the people who wrote the OID4VCI and OID4VP specifications had spent years working on Aries and AnonCreds.
It ran real pilots. Dozens of government and enterprise pilots ran on this stack. Canada's provincial digital identity initiatives. The EU's ESSIF programme. Enterprise credentialing for healthcare. These pilots generated the hard-won lessons that shaped the design of what came next.
AnonCreds' privacy model was genuinely ahead of its time. The zero-knowledge predicate proofs in AnonCreds — prove you are over 18 without revealing your date of birth — are a real cryptographic capability that SD-JWT, the format that replaced it, only approximates. The privacy purists who remain attached to AnonCreds have a legitimate point.
Where adoption broke down
Despite real achievements, the Hyperledger stack never achieved the broad adoption its architects hoped for. The reasons are worth understanding in detail, because they are exactly what the next generation was designed to fix.
Problem 1: You needed a blockchain to start
To issue a credential using AnonCreds, the issuer must first write a credential schema and credential definition to the Indy ledger. Writing to the ledger requires:
- A running Indy network
- A governance process to become a trusted writer
- Ongoing maintenance of ledger nodes
A developer wanting to experiment with SSI could not simply run npm install and start. They needed to either connect to the Sovrin network (requiring a permission process) or run a local Indy ledger (requiring Docker and non-trivial configuration). The barrier to the first credential was days, not hours.
For a production government deployment, this overhead is acceptable. For a developer building a proof of concept, it is a dealbreaker.
Problem 2: DIDComm is not the web
The web is built on HTTPS — a stateless, request-response protocol that every developer understands. Every HTTP client library, every API testing tool, every proxy, every load balancer, every monitoring system understands HTTPS.
DIDComm is none of these things. It is a stateful, encrypted, peer-to-peer messaging protocol that requires:
- A persistent connection concept (unlike REST)
- Encrypted message envelopes using DID-based keys
- An agent architecture on both ends
- A mediator for mobile endpoints
Debugging DIDComm flows required specialist tools. Integrating DIDComm into an existing backend service meant replacing or wrapping the entire HTTP layer with something DIDComm-aware. Most enterprises have existing OAuth and REST infrastructure. None of it spoke DIDComm.
The integration cost: A team building an identity verifier on a standard web stack faced a choice between wrapping their entire HTTP infrastructure in DIDComm, or building a separate DIDComm sidecar service. Either path required significant specialist knowledge and new infrastructure.
Problem 3: AnonCreds did not fit the JWT world
By 2020, JWTs were everywhere. Every backend developer understood them. Every API gateway could validate them. Every OAuth library produced and consumed them.
AnonCreds are not JWTs. They are a distinct binary format, derived from Camenisch-Lysyanskaya signatures and Pedersen commitments, that requires specific cryptographic libraries. These libraries were not available in every language. They were not well-documented outside the Hyperledger community. Integration required specialist knowledge that most development teams simply did not have.
The irony is that AnonCreds' unique feature — zero-knowledge predicate proofs — was exactly what made it incompatible. The same cryptography that enables "prove you are over 18 without revealing your date of birth" also makes the format fundamentally different from anything in the existing web infrastructure toolkit.
Problem 4: The mediator problem in production
Every DIDComm-based mobile wallet requires a mediator. This means:
- Someone must operate the mediator infrastructure
- The mediator becomes a point of centralisation in a supposedly decentralised system
- Wallet vendors must choose a mediator provider, or run their own
- If the mediator goes down, the wallet cannot receive messages
In practice, almost every DIDComm wallet deployment ended up relying on mediator services run by a small number of providers. The decentralisation of the trust model did not extend to the messaging infrastructure.
Problem 5: 100 DID methods with no winner
DID methods are the different ways of publishing and resolving DID documents. The W3C DID registry lists over 100. The Hyperledger ecosystem used did:sov (Sovrin), did:indy, did:peer, and others. Each requires its own resolver. Wallet interoperability across DID methods was always a work-in-progress.
A verifier building a credential checker faced a choice: implement resolvers for every DID method they might encounter, or restrict themselves to specific methods and lock out wallets using different ones.
The verdict
The Hyperledger SSI stack was an honest attempt to solve a hard problem in a moment when blockchain was the obvious tool for decentralised trust. It demonstrated that the model works, built a global community of practitioners, and ran real pilots that produced real lessons.
But it required a blockchain when most use cases did not need one. It required DIDComm when HTTPS would have done. It required AnonCreds when JWT would have been sufficient. Each requirement added a specialist barrier that limited the pool of developers who could build with it.
The community that built this stack recognised these problems. The people who designed OID4VCI, OID4VP, and SD-JWT did not dismiss the Hyperledger work — they learned from it. They kept what mattered (the trust model, the issuer-holder-verifier triangle, selective disclosure) and replaced what did not (the blockchain dependency, the bespoke transport, the non-standard credential format).
The next chapter explains what they built instead.
Summary
The Hyperledger SSI stack — Indy, Aries, ACA-Py, AnonCreds, DIDComm — was the first serious implementation of self-sovereign identity. It proved the model worked, built a global community, and ran real pilots. But it required blockchain infrastructure, a bespoke transport protocol, and a non-standard credential format that collectively created a high barrier to adoption. The next generation was designed to solve these specific problems.
| Component | What it did | Why it was hard |
|---|---|---|
| Hyperledger Indy | Decentralised trust anchor | Required blockchain; permission process to write |
| DIDComm | Secure agent messaging | Not HTTPS; required specialist tooling |
| AnonCreds | Privacy-preserving credentials | Not JWT; limited library support |
| Mediator | Mobile message relay | New infrastructure; single point of failure |
| ACA-Py / Aries | Agent framework | Steep learning curve; not REST-native |