PART 1: DECOUPLING THE RELIANCE ON HYPERLEDGER INDY AND CREATING MORE EXTENSIBLE ANONCREDS OBJECTS WITH CHEQD.
Co-authored by Alex Tweeddale (Product Manager & Governance Lead), Ross Power (Product Manager), and Ankur Banerjee (CTO/Co-founder).
Introduction
We are very excited to announce that the on-ledger resources feature released on cheqd mainnet allows for developers to support AnonCreds natively on the cheqd network.
Supporting AnonCreds on cheqd is a landmark achievement, since they have previously been tightly coupled with Hyperledger Indy chains. We are the first network to successfully decouple this dependency.
cheqd now provides support for AnonCreds, and in doing so, it remains compliant with W3C DID Core Spec, enabling Schemas, CredDefs, Revocation Registry Definitions and Revocation Registry Entries to be created using on-ledger resources, identifiable via DID URLs. This work is seminal in creating a broader ecosystem-agnostic ledger-layer, which supports greater interoperability for self-sovereign identity (SSI).
What are “AnonCreds”?
AnonCreds are a type or “flavour” of Verifiable Credentials that are utilised predominantly by Hyperledger Indy for ledger code and interactions, Hyperledger Ursa for cryptographic libraries, and the Hyperledger Aries codebase for agent, wallet, and credentialing code.
AnonCreds are now widely adopted, through organisations, such as the Government of British Columbia, IDunion and the IATA Travel Pass.
We carried out a survey earlier in 2022, finding that AnonCreds constituted the highest adopted (or roadmapped) Credential type amongst our respondents in 2022:
- 45.9% AnonCreds;
- 40.5% JSON based JWT;
- 40.5% JSON-lD with BBS+ signatures; and
- 32.5% JSON-LD.
(The percentages represent the percentage of respondents who selected the Credential type to support in 2022).
The respondents here were largely partners of cheqd. Therefore, to fully support all our partners and their existing clients within our network, we needed to build a way to support AnonCreds.
Why are AnonCreds a contentious issue?
For anyone in the self-sovereign identity (SSI) community, there is no avoiding the fact that AnonCreds divide the opinion of the community.
AnonCreds were originally designed to provide additional privacy benefits, compared with JSON and JSON-LD based Verifiable Credentials. To achieve these privacy benefits, AnonCreds utilise a series of bespoke technical components, including:
- Camenisch-Lysyanskaya (CL-Signatures) to encode individual claims for the purpose of enabling selective disclosure.
- Link secrets written into Credential Definitions, used when issuing AnonCreds to: (a) bind the issued Credentials to a particular holder; and (b) enable the holder to present a Zero-Knowledge Proof to a verifier without using a correlatable identifier.
- Hyperledger-Indy specific transaction syntax for on-ledger schemas, credential definitions, revocation registry definitions and revocation registry entries.
- Cryptographic accumulator deltas on-ledger, compiled into off-ledger ‘tails files’, for the purpose of asserting proofs of non-revocation, while maintaining privacy for AnonCreds holders.
These bespoke technical components afford AnonCreds a degree of ingenuity; but it comes at the cost of interoperability.
Vendor Lock-in
A bit like how Apple products only really work with other Apple products; AnonCreds only really work with Hyperledger Indy, and are largely tied to Hyperledger Aries libraries to be issued and consumed.
Image comparing AnonCreds and Apple compatibility. Source.
Historically, AnonCreds cannot be written to other Layer 1 Utilities, since Credential Definitions and CL-Schemas are custom Indy-specific transactions which are not conformant with W3C DID Core. This shoehorns adopters into a particular tech stack, which although open source, is largely reliant on the Indy/Aries community for updates, since there is no formalised Standard approved by a reputable international body like IETF or W3C. It is worth noting, however, that AnonCreds v1 is being proposed as a Standard and is in the process of being taken to the Internet Engineering Task Force (IETF).
Scalability
The use of ZKP-CL signatures provides AnonCreds benefits from a privacy perspective, yet, it also requires the computation of very large files which can lead to inefficiencies when used at scale in production environments.
Kaliya Young’s recent blog on Being “Real” about Hyperledger Indy & Aries / Anoncreds highlights many of the scalability issues around CL-Signatures well.
Similarly, the “tails files” used in Indy revocation suffer from similar inefficiencies. Each “tails file” can contain up to 20,000 revocation entries; and in a highly utilised ecosystem, there may be large amounts of these tails files, of 20,000 entries archived. On making a request of non-revocation and querying a tails file of this size, it may take a much longer time than usual to return a proof, creating a slower user experience than standard centralised models.
Owing to the benefits, as well as the tradeoffs, we previously concluded that AnonCreds in their current format have led to a degree of short-termism and long-termism within the community. Vendors with clients knocking on their door and asking for a product tomorrow are swaying towards short-term solutions which work now (such as AnonCreds which contains privacy-preserving revocation and the capability for predicate proofs).
Whereas, enthusiasts and SSI visionaries are looking at a longer-term vision of harmonisation and wide-barrelled interoperability (such as JSON-LD with BBS+ signatures or even AnonCreds V2 with BBS+ signatures). This is because BBS+ signatures provide a lot of the same benefits as AnonCreds (CL signatures), but with much smaller file sizes. Nonetheless, at cheqd we have acknowledged that there is a value in supporting both types of Verifiable Credentials.
Supporting AnonCreds on cheqd
Our first port of call in supporting AnonCreds was differentiating what makes AnonCreds distinct from other types of Credentials in terms of what goes on the ledger, and looking at ways that we could accommodate for those differences using cheqd functionality.
Decoupling AnonCreds from Indy
The key features of what makes an AnonCred exist at two distinct levels:
- Ledger level: What must be written to a verifiable data registry for AnonCreds to be created and functional in practice?
- Credential and SDK level: What cryptographic techniques must be employed within an SDK to give AnonCreds their privacy-preserving features?
For the existing AnonCreds stack, on Hyperledger Indy, these two levels can be represented by Figure 1 below:
Figure 1: How Indy and Aries interact for AnonCreds support
Here, Hyperledger Indy is important for supporting AnonCreds since it has to-date been the only identity-blockchain which can natively support DIDs, Schemas, Credential Definitions (and optional Revocation Registry) transactions written to the ledger.
Our hypothesis in supporting AnonCreds was that if we were able to replicate the functionality of the Ledger layer, the SDK and credential layer would be able to fit on top, without any wholesale changes in client applications that currently use AnonCreds. This would decouple the dependency on Hyperledger Indy, creating a much broader and widely interoperable ecosystem for AnonCreds.
Figure 2: How cheqd and Aries theoretically can interact for AnonCreds support
However, we did not want to build a carbon copy of Hyperledger Indy. As previously discussed, Hyperledger Indy is contentious for multiple reasons, scalability, and interoperability.
For this reason, we wanted to explore the option of supporting Credential Definitions and Schemas on-ledger, but in a way which directly conformed with W3C DID Core and with greater scalability.
Composition of AnonCreds Object identifiers
To reach a composition of Schemas, CredDefs, RevRegDefs and RevRegEntries on-ledger which is W3C DID Core compliant, it is important to understand exactly how these bespoke transactions are composed on Hyperledger Indy, and why this did not achieve conformance with the standard.
What goes into a Legacy AnonCreds ID?
Historically, AnonCreds Identifiers for scheamas, CredDefs and Revocation writes have been composite strings, recognised only by Hyperledger Aries and Indy applications.
For example, AnonCreds on-ledger schema_id, contain the following information:
- Publisher DID: is a string. The DID of the Schema Publisher.
- Object type: An integer denoting the type of object. 2 is used for Schemas.
- Name: is a string, the name of the schema
- Version: is a string, the version of the schema in semver format. The three part, period (“.”) separated format MAY be enforced.
The schema_id therefore was formatted in the following way:
<publisherDid>:<objectType>:<name>:<version>
For example, a Legacy AnonCreds schema_id could be:
7BPMqYgYLQni258J8JPS8K:2:degreeSchema:1.5.7
The problem with this approach is that it:
- Ties AnonCreds to Hyperledger Indy, since Indy is the only possible chain which can provide all the required content for schemas, CredDefs and Revocation writes;
- Limits client applications to expect a very specific identifier format for AnonCreds Objects.
Therefore, to decouple AnonCreds from Hyperledger Indy it has been important to move away from this identifier format and to create a more extensible approach to providing client applications the required information.
AnonCreds Specification expansion
Recently, the AnonCreds specification has evolved to allow different ‘AnonCreds Object Methods’ which do not necessarily need to conform to the same representation as the legacy identifiers.
This approach gives different Object Methods the flexibility to define their own AnonCreds Object Identifier formats. This is a welcome change which provides greater flexibility in how AnonCreds Objects may be represented on different chains. Using this extension of the AnonCreds specification, cheqd has been able to create its own AnonCreds Object Method.
cheqd AnonCreds Object Method
In an earlier blog, we discussed our approach to resources on cheqd at length and highlighted the benefits of using on-ledger schemas, compared to other existing solutions such as schema.org.
cheqd AnonCreds Objects build directly on this approach, in that we wanted to create an identifiable path to each specific AnonCreds Object using DID URLs.
Example of cheqd DID URL for schema resource
- cheqd AnonCreds Schemas
- cheqd AnonCreds CredDefs
- cheqd AnonCreds Revocation Registry Definitions
- cheqd AnonCreds Revocation Registry Entries
Conclusion and next steps
Through the use of the resource module, cheqd is able to support all AnonCreds specific Objects within the parameters of DID Core, by identifying each Object and future Object versions with DID URLs.
This creates an elegant platform for AnonCreds to be issued on-top, which will allow cheqd to support any SSI vendor in the marketplace at a technical level. We have started with integration into Aries Framework Javascript (AFJ) and are looking to expand into Aries Cloud Agent Python (ACA-Py) as well as Aries Framework .NET. Read more about our plans in Part 2!
We look forward to working with our partners and the broader SSI community to see how we can innovate together using this new functionality, and decouple AnonCreds dependencies further.
As always, we’d love to hear your thoughts on our work and how resources on-ledger, or AnonCreds on cheqd could improve your product offering. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.
AnonCreds Indy-Pendence was originally published in cheqd on Medium, where people are continuing the conversation by highlighting and responding to this story.
