Identity

Executive Summary

This article surfaces a synthesis of challenges / concerns about Hyperledger Indy & Aries / Anoncreds, the most marketed Self-Sovereign Identity technical stack. It is aimed to provide both business and technical decision makers a better understanding of the real technical issues and related business risks of Hyperledger Indy & Aries / Anoncreds, which have not been shared and discussed openly or publicly as the author believes need to be.

Who I am

My name is Kaliya Young. You may know me as the Identity Woman. I have been working on user-centric identity and most recently Self-Sovereign Identity standards for the past 20 years. Something fun has started to happen in recent years at identity events, more people who don’t know me are asking me if I have heard of or been to the Internet Identity Workshop (IIW), the landmark community forum for identity standard development I co-founded 17 years ago and still co-lead today. 

As someone who didn’t come from a technical background and doesn’t write code, I have made tremendous efforts to reach where I am today, able to explain technology accurately and facilitate deep technical discussions and collaborations. For years, I have participated in technical sessions and engaged myself in all types of forums in technical communities building user-centric identity to learn about technical details and ask questions.

I have exerted determination and persistence throughout my career, because I deeply care about what I do, and I feel that I owe it to those who have helped me become a community leader to do what I believe is right. They don’t always share the same views with me but they believe in my genuine intention and my capability to provide unique value to this emerging area of technology. I have deep respect for all of them and others who have been working diligently to make user-centric identity a reality, many of whom helped shape the narratives of this article when they knew they might be affected by its release.  

Here, I thank all of you who helped me capture the technical details in a truthful manner in this article, and my business partner, Lucy Yang, who supported me in making the difficult decision to write it and helped review and edit it. 

How Open Standards Get to Market 

Open standards are developed by a large technical community of people who see the need to lay some foundational ground of how to do a particular thing (If you are not familiar with open standards, here is a podcast that may be helpful). Due to the scale of efforts and influence, it always takes time for open standards to emerge, evolve and mature. A mature standard needs to go through multiple versions of iteration spanning across at least a decade or even more. During this time, you see a community of business and technical developers, normally a growing one, implementing and marketing a standard in many different ways and then feeding their experience back to the standard group in order to shape the next generation of the standard for the better. 

Self-Sovereign Identity (SSI) has just been through its first six years of early exploration, during which we see several paths of technology implementation emerge, co-opetition (cooperation between commercial competitors for their mutual advantage) happens, and convergence takes place in time. The W3C Verifiable Credentials (VCs) standard is a good example with the existence of different flavors of VCs (You can find more about the VC flavors in this article I wrote and the associated infographic I developed with Lucy). 

If you are a business decision maker looking into SSI, you may wonder if these technical choices matter, especially when the standards are at their early stages. The answer is yes, because all these implementation experiences are going to influence where the standard goes in the future. When a poor technology choice today later becomes a part of a standard, it will have a pervasively negative impact on all of us. It is essential for the pioneers of an industry to make choices to implement and explore possibilities as well as conduct honest critical evaluation of those choices as they meet the real world, so that the next generation of standards can take this into account as they evolve.

I have encountered business leaders who believe in the absolute power of market forces, thus making business decisions without knowing enough or at all about technical details, as well as technical leaders who see market dominance as the solution to a troubled path. While it is true that the market in general rewards whatever is marketed the best, not necessarily built the best, it is also true that critiques for and against different options is an important part of how a market should function, because many want to avoid another market success like the browser cookies, which has turned out to be a “disaster” for netizens.

I believe that those who picked early and explored a pathway on the landscape of potential should all be applauded – it takes a lot of courage to heavily invest in an implementation path at the very early stage of standard development. If the path doesn’t turn out well, it will have a significant impact on the business(es) of those who make significant early investments, especially if they need to abandon most of what they have built. The decision to pivot the technology becomes even more difficult if one has a relatively sizable business, a client and partner base relying on their technology, a group of early investors, and a market leader reputation to maintain. Because of that, it is almost understandable why some want to hold on tight to a problematic path even when they are aware of the issues with their technology stack. And it is with this understanding and respect for all early adopters / implementers that I am writing this article about Hyperledger Indy & Aries / Anoncreds, which so far has been the most-marketed SSI technical stack but not built as well as marketed nor the best one in the market.

Being “Real” about Hyperledger Indy & Aries / AnonCreds 

Hyperledger Indy and Aries are two open source projects at the Hyperledger Foundation, a sub-organization of the Linux Foundation. Together with Hyperledger Ursa, the three projects form the core blockchain-based SSI stack at Hyperledger. Aries and Ursa initially originated from Indy, but later became separate projects focusing on different technical aspects:

• Indy is a combination of Indy SDK (crypto and ledger communication library) and Indy Node (the ledger implementation code). The Indy blockchain holds the credential schemas and Decentralized Identifiers (DIDs) of issuers and potentially governance registry listings. 
• Aries is the code for agent applications that all actors in the identity ecosystem can use – issuers, holders and verifiers. This code writes to Indy ledgers and facilitates data exchange, making Indy and Aries a couple tightly implemented together. 
• Ursa is the cryptographic library used by Indy and Aries. 
• Anoncreds (ZKP-CL) is a low-level protocol for data exchange that defines data model (VC flavor) and interaction workflows that Indy and Aries use.

I am going to surface a synthesis of challenges / concerns about Hyperledger Indy & Aries / Anoncreds that many have found and brought to my attention. These concerns have existed for some time and have caused friction internal to the community without much public knowledge of them. As SSI is becoming more widely considered by governments, businesses and others around the world, I feel the professional responsibility to raise these lesser-known issues of the most marketed technical SSI option and say them out loud. It is important for anyone considering Hyperledger Indy & Aries / Anoncreds to know and understand these issues and their related business risks before making their decisions. 

1. LACK OF STANDARDIZATION AND WEAK STANDARD ALIGNMENT

•  No well-documented and agreed-upon specification

Open source code and open standard are two different things. Open standards define a recipe that allow people to implement the same thing in different ways, whether open source or not. By following the same recipe, we ensure some very basic interoperability across software / internet applications, for example, we can send emails from Gmail to Outlook. This interoperability is very important for identity credentials, as we need to use them pretty much everywhere. 

Indy / Aries have only been open source code bases that didn’t go through a standardization process to have a well-documented and agreed-upon specification. Those who don’t want to use the code bases can implement what they think the recipe is at their own risk, creating potential interoperability and other challenges down the road. And there is no specification for the Anoncreds format (implemented in the Indy code base now) that could be used to test different implementations, and there is no alternative implementation of Anoncreds to Indy. One can use wrappers to implement the Indy code into another programming language, but this is most likely going to cause memory management and error handling issues, making it hard to build stable software.

Due to market pressure, the Indy / Aries community recently started the standardization process for Anoncreds, years behind other credential formats that have already been engaged in standardization for years.

• Anoncreds (ZKP-CL) not aligning with the core W3C VC Data Model 

The core VC data model uses JWT or JSON-LD data formats, both leveraging the material in the credentials themselves and not needing to pull down a schema from a ledger for verifications. 

Anoncreds, which doesn’t use any standard data representation technology or VC data model(s), has its own format called ZKP-CL. The schema of this format is built using a JSON structure, but unlike the VC formats mentioned above, when a credential is created using ZKP-CL, the issuer must create a credential schema and write it to an (Indy) ledger for the credentials conforming to that schema to be verifiable. As a result, the verifiers have to get the schemas for the particular credential from the ledger and use that in the calculation to understand the veracity of the credential, making computation more intensive.

The discussion of Anoncreds 2.0 has been underway for several years, including a version of Anoncreds that uses BBS signatures, providing it some potential for adopting different VC data models. However, the progress on this effort has been extremely slow, and this effort will essentially mean reinventing the entirety of Anoncreds stack (Indy SDK and Node). 

2. LACK OF TECHNICAL RIGOR

• An old, less performant signature algorithm that is not suitable for a new product

Indy & Aries / Anoncreds is using a signature algorithm called the Camenisch-Lysyanskaya (CL) signature, based on the work by Jan Camenisch and Anna Lysyanskaya published in 2001-2004. CL-signatures uses 2048-bit keys based on RSA cryptography, which is actively being phased out, deprecated, and marked as “legacy” algorithms in some contexts. It is questionable to put it into new technical deployments that are at the beginning of their lifecycle. 

CL-signatures, slower and less performant than its modern alternatives, can lead to a set of trade offs that create security issues. For example, key sizes have to be larger to ensure security, requiring more bandwidth to transmit keys around. The larger key sizes also cause slow validation / transaction time (up to 7 seconds for a validation and approximately 30 seconds for credential definition generation when a new issuer is provisioned). The computing requirements also result in the need for powerful user devices for wallets, which means only users with powerful enough mobile devices can use the technology.

Furthermore, CL-signatures are too special to be supported by mainstream secure enclaves and secure elements. As a result, there is no way to protect the cryptographic key material used for holder binding in hardware. That means protection against credential theft and impersonation is software-based only, which is not sufficient for substantial and high assurance use cases. For example, any legitimate user can extract their COVID credential along with its cryptographic commitment to the wallet (link secret) from their phone and sell it on the Internet, meaning potentially millions of users could present a false credential. Given the unlinkability of Anoncreds, it would be impossible to determine which credential was sold – so it cannot be revoked to stop the fraud. 

Reputable government agencies such as NIST (US National Institute for Standards in Technology) and BSI (German Federal Office for Information Security) have never approved CL-signatures for government use, an indication that many government projects won’t be able to adopt Anoncreds in its current form, which has a dependency on CL-signatures. 

• No proper review and audit of the CL-signatures algorithm implementation

It can take years for new cryptographic curves and primitives coming out of academic work / paper to be ready for scaled deployment in real-world environments. Products that leverage cryptography, in order to ensure safe deployment, normally have a particular life cycle development pathway involving massive testing and vetting by experts.

When Hyperledger accepted the proposed Indy implementation as a donation, the CL-signatures was not battle tested to the same degree as more commonly used cryptographic schemes such as Ed25519 in TLS to secure the Internet or secp256k1 to secure billions of dollars of assets on Bitcoin and Ethereum. There were a significant number of steps missing, including an audit and peer review by cryptographic expert communities. For example, the Internet Engineering Task Force (IETF), a major standard organization for technical standards that make up the Internet protocol suite, delegates its cryptographic audit and review to IRTF Crypto Forum Research Group (CFRG). 

Rigorous testing is particularly important for implementation of cryptographic products since most often cryptographic issues emerge from the actual libraries / code bases of cryptographic operations which expose unsafety and vulnerability, rather than the cryptography itself.

• Miscommunication and overhype about link secrets and their role in subject-holder binding

Indy & Aries / Anoncreds implemented an “innovative” idea that embeds a “link secret”, a long number (same for every credential issued into a wallet), within another long number (different for every credential issued into the wallet). This has been communicated as the secret sauce that one implements Anoncreds can use to prove credentials in the same wallet are issued to the same person. This is not only an inaccurate depiction of the capability of the technology stack (as explained in an earlier point regarding CL-signatures) but also a miscommunication of the value of link secrets. 

As a matter of fact, link secrets can only ensure that two credentials share a common secret value. One could have two people use the same wallet to collect different credentials, or create a link secret that is in two different wallets and present attributes of credentials from both wallets. In these scenarios, verifiers won’t be able to know if the credentials in the same wallet are issued to the same person. Therefore, even though link secrets can provide value, it is important we have an accurate understanding of its value and don’t rely on/communicate the mechanism for assurances it can’t provide. 

This communication gap creates expectations and misplaced assumptions that could lead to significant security issues. An IEEE paper in 2019 explained it in more depth.

3. SERIOUS TECHNICAL, SCALABILITY AND GOVERNANCE ISSUES

• Indy & Aries / Anoncreds was constructed in a way that limited cryptographic agility or “upgradeability” or maintainability or extensibility or portability

Cryptography in large-scale applications has grown progressively more modular over the last decade or so, making it possible for a specification and technology stack to swap out the old algorithm for a new one. 

However, Indy was designed to conflate data representation with the cryptographic algorithmic implementation, making it cryptographically fragile – when the algorithms are cracked, the whole stack breaks. There is no “next algorithm” to migrate to relative to the same data structure. This means that when it does break, the whole stack needs to be re-built from scratch. 

Therefore, it is a normative best practice to use cryptographic signatures around data in a way that does not conflate a data representation with the cryptographic algorithms. Some well-specified options include Data Integrity (DI), CBOR Object Signing and Encryption (COSE), and Javascript Object Signing and Encryption (JOSE).

• Indy is not able to support large-scale issuance, verification and revocation

Indy was originally built to be single-threaded so that it could support a native token for in-network economics that required double-spend proofing. However, this significantly impacted Indy wallets’ ability to support large-scale implementations. Some implementers validated this scalability issue through their own experience, for example, using the Indy SDK to issue a bit over 18,000 credentials, which ended up taking four hours. One can potentially improve the situation by implementing Aries Askar, which is a standalone solution not pluggable into the Indy SDK.

On the verification side, if 1000 people log into a website at the same time, the verification speed will be very slow and cost prohibitively high. When looking at high scale applications such as the New York COVID certificate application which needed to support millions of verifications per day, an Indy ledger would just fall over. 

The credential revocation scheme of Indy is not scalable at high volumes either. One always has to balance performance / functionality with user privacy. A large batch size of revocation list, e.g. 10 million revoked credentials, will better guarantee user privacy through obfuscation and effectively prevent tracking of users on-chain. However, an implementer of Indy said that they could only set the batch size at 10K credentials to keep a reasonable performance. An additional issue on the mobile side – larger batch size will result in larger tails / cryptographic file that a user needs to download from the Indy ledger. 

You can find a research paper that came out in April 2022 here, which documented very clearly the scalability issues with Indy ledgers and the approach of how verifications are processed using on-chain located schemas for credentials:

“We conclude that issues of Trust Registry scalability have multiple facets. While Hyperledger Indy captures data useful to underpin a decentralized identity scheme, the knock-on effect of its scalability limitations may indeed place constraints on properties of security and decentralization. The current credential verification process relies on transaction processing by a ledger with transaction processing bottlenecks, which may constrain the ideal of non-repudiation.”

• Indy networks have a governance and economic issue 

One of the features people like about blockchains is that they provide for a network of nodes that all agree on a certain state – this means that people are not depending on one database or trusting one party to maintain it. Different parties can work together to maintain a network that all trust. Different ledgers can scale to different sizes of node networks. The Bitcoin network has tens of thousands of nodes for example, across “light” and “full” nodes.

Recent years have seen major advances as node-networking and consensus mechanisms evolve in tandem to power global blockchains. However, if you run an Indy network with more than 25 active write and consensus nodes operating at a time, performance plummets. The limitation poses serious governance issues as it is nearly impossible for Indy networks to have more than a small number of nodes in active operations.

Another major governance issue comes from the configuration of Indy’s auth_rules. By default, it takes one “Trustee” to do almost anything other than freezing the network (which takes three trustees), such as removing DIDs, changing any rule, setting fees, minting tokens, and / or even adding new trustees. Most Indy networks have adjusted the number from one to three “trustees” as the number required to do anything. This means you only need three individuals to collude to take down the entire network, or three individuals’ emails to phish to take down the entire network, or three trustees to erase information from the ledger. There have been Indy networks where more than half of their trustees all come from the same company – meaning that company effectively controls the network. 

The governance issues plus technical challenges make it hard for Indy networks to make any economic sense to exist as stand-alone ledgers just for storing credential schemas and DID Documents. That is why some early Indy networks have faced concerns of going down because there are not enough people/organizations wanting to operate nodes.

• Aries has limited adaptability for mobile

Beyond the above-mentioned computing requirements caused by the CL-signatures that lead to limitations on the mobile device side, there are also limitations at the application development level.

Aries is an umbrella of several agent frameworks written in different languages, which differ in feature set and community support. It is not possible to incorporate Aries into a native iOS app because there is no “Aries Framework Swift” (Swift is the native programming language for iOS), so nobody with a native iOS app can add an Aries wallet to it. This severely limits its adoptability. Some have tried to develop an Aries Framework Swift but gave up due to a multitude of challenges. 

The only two Aries frameworks that work on mobile today are React-Native and Xamarin (not actively supported anymore), which power a decreasing number of mobile apps in the market, as native Swift and cross-OS Flutter take up more and more market share in recent years. 

Additionally, due to the large number of external dependencies Indy has, such as OpenSSL, Libzmp, a React-Native wallet installing the Aries libraries can take up 70+ MB space, a huge amount for those who don’t have the latest iPhones. The external dependencies also make it a pain for developers to support mobile platforms with Aries. 

Finding a Way Forward Together as a Community

I am releasing this article right before the Hyperledger Global Forum in Dublin, Ireland from September 12-13, 2022, where I am speaking on multiple occasions about Self-Sovereign Identity / Decentralized Identity. I look forward to engaging there with anyone about this article, whether you are happy to see these issues finally being publicly shared or concerned about how it will influence your business. 

I have rooted my entire career in this community and care about all of you who are working hard to make our common mission a reality. As the world is paying more attention to our work and eager to work with us, I am committed to helping us find a way forward as a community.